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Apple Profile_Interface: 


A more complete description of the Apple/Profile interface may 
be found in the document “EXTERNAL REFERENCE SPECIFICATION ¢E.R.S) 


PIPPIN 
1981. 


HARDWARE" by Dick Woolley and Wolfgang Dirks, dated April 16, 


There are 3S control lines to/from the Apple ProFile Interface Card: 


1. 


ce 


4, 


ee 


yg 


Parity 

This line is 1 Bit of odd parity € even parity across the 
cable >. The Interface Card is responsible for monitoring 
this signal: the controller calculates parity only when it 
sends aword across the Bus; the controller does not check 
parity when a word is sent from the host, instead the parity 
bit is 1S generated once more on the controller side of the 
bus and then routed back to the hast. 


CMD ¢ Command/Attention: Asserted by Host, Active high )D 
This signal is one of two handshake signals across the 
interface bus. Keep in mind that even though the host and 
controller are two autonomous machines, the host is always 
considered the master and the controller the slave ¢ in this 
configuration >. When the host wishes to initiate a transfer 
to the controller it must first check if BSY ¢ discussed 
below ) is active. If BSY is active then the Host must wait ¢ 
hopefully it will set a DeadMan timer and catch a "sick" 
controller > until BSY is no longer active, 


BSY ¢ Busy: Asserted by Controller, Active High dD 
This signal is the dual of CMD, in other words this is the 
Signal with which the controller can hold off the host for an 
indefinate period of time while it is “BUSY" performing same 
task. | 


STRB ¢ Strobe: Asserted By the Hast, Active High >) 
Strobe is used to signal to the controller/host pair that 


data is valid on the bus. 


R/W ¢ Read/Write: asserted By the Host, Write is Active Low 


This signal is used Br the Host to indicate to the contraller 
which direction data is to be going during a transmission. 
Read is used ta direct data out of the contraller inta the 


host and the opposite condition is true for Write. 
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Profile Communication Protocal: 


The following is an explanation of the protocol that is used 
to provide communication between the host and the controller: 


¢ Some explanation of the symbols that. I am using is probably 
called for at this point. > 


“<,>% : The bracket symbols mean that the information inclosed 
within them are manditory. - 


ee : The square bracket symbols mean that the !tnformation 
inclosed is optional. 


‘1’ : The vertical bar symbols is used to indicate an alternative 
or "OR" condition. For example, AIB can be thought of as “Either | 
A OR B", 


“s:=’ : This symbols is used ta indicate a definition or 
equivalence. | 


“€,3° 2: Curly Brackets are used to denote comments. 


‘+’ : The plus sign is as an addition symbol. 
“NULL Y : This Key word indicates the empty set, or im tome cases, 


the fact that the function whose value is NULL can be ignored. An 
example iss 


Argle-Bargle ::= < NULL > 


Essentially you can forget that Argle_Bargle exists for this 
context. | 


Ao™ 
ee 
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PROFILE_COMMANDS 


| These commands are currently by the SOS driver. Widget is 
designed to be Backwards compatible with the current ProFile driver, 
and'"to that end there exists the three ProFile system commands: 
Read, Write, and Write Verify. | 


Profile Commands: 


Opcode | Definition 
$Oo Read Logical Block 
$H 1 Write Logical Block 
$G2 Write/Verify Lagical Block 
The three Profile commands behave in exactly the same fashion as 
do the corresponding instructions on ProFile, with one small 
exception: the Read Logical block command does not include 


_. information concerning Retry count. or Sparing threshold ¢€ however, 

( secause of a side effect in the way that the Host/Controller 
imterface was designed, the Host may write as many command bytes to 
the controller as it chooses. The controller will only decode the 
first 4. 3. The form of each command is: 


{$48 | $871 | S$B82> < 3 Bytes of Logical Block Address +7 


There are twa ‘special’ logical addresses defined in the ProFile 
protocol, namely $FFFFFF € -1 } and SFFFFFE ¢ -2 +. Logical address 
< w~fL > returns as it’s value Device_ID € as explained under the 
Widget Diagnostic commands } and Logical address < -2 > returns as 
it”’s value Widget’s spare table structure im it’s raw? form. It 
should be noted that if at any time Widget can not pass it’s self 
test that it will refuse to communicate via logical commands € bath 
ProFile and System type commands }. Widget will respond to 
Diagnostic commands at all times, however. 


The rest of the commands availadle on Widget are a complete 
departure from the ProFile way of doing things. The new form of 
command is: 


¢ < Command Byte > 
.- TAStTPUCt ron byte 2 
C Inetructton_Parameter_String J 
« CheckByte > ) 


Command Byte ::= < CommandType_Nibble + CommandLlength_Nibile > | 
CommandType Nibble ::= < Diagnostic _Command | System_Command > 


Diagnostic Command ::= ¢ $14 > 
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System_Command ::= < $29 > 


CommandLength_Nibble ::= Count of all bytes in the command string 


NOT including the first one. This length is used anly to calculate. 


the checkbyte, and not to parse the command, therefore there is a 
large variety of commands that perform exactly the same function but 
differ in format in that their lengths are not the same. 


IF System_Command 
THEN Instruction_Byte i:= <Sys_Read | Sys_Write | 
Sys_WrVer > 


IF Diagnostic_Command : 
THEN Instruction_Byte :: 


il 
“A 


Read _ ID | 

Read _Controller_Status | 
Read Servo_Status | 

Send Servo Command | 
Send Seek | 
Send_Restore | 

Set Recovery | 

Soft Reset | 

Send Park | 

Diag Read | 

Diag ReadHeader | 
Diag_Write | 

Store Map | 

Read SpareTable | 

Write SpareTable | 
Format Track | | 
Initialize SpareTable | 
Read Abort Stat | 

Reset Servo | 

scan > 


Inetruction_Parameter_String ::= ¢ This string is inetructian 
dependent, and will be formally specified at the same time as the 
individual instructions. 3 : 


CnheckByte ::= € This Brte is the ones-complement of the sum, in 
MOD—-256 arithmetic, af all the bytes including the Command_Brte 3}. 


x 


: 
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DIAGNOSTIC_COMMANDS 


Widget’s "personality", or the manner in which it behaves, can be 
thought of as having two distinct parts: 1) that portion that is 
‘dictated by the hardware and 2) that portion that is controlled by 


. the firmware. As trite as that last statement may seem oan the 


surface, the fact remains that the part of Widget that is the 
hardware is not easily molded to adapt to different environments. 
The same is true, But not quite in the same manner, for the firmware 
- the code is locked in a ROM of some sort and costs a lot to 
change. - How then can Widget’s “personality" be changed ¢ on-the-fly 
> ta “adapt" to anew environment? The answer in this case to 
architect the firmware in a layered fashion: build the intelligence 
required to run Widget in it’s normal operating mode from a pool of 
discrete, primitive functions; these primitive functions in most 
cases have only one particular task that they are capable of 
completing. The implication of this architecture is that with very 

little effort these same primitive functions are availble ta the 
host system, and thus make Widget a little “Schizoid". Such Juxuries 


resto not come without their hidden costs, however. For one thing, the 
S Jidget controller is slightly more expensive to manufacture € a cost 


that I believe pales in the sight of the added test/diagqnastic 
capabilities } because of the additional code space required for al] 
the bells and whistles, and another is that someone must now develop 
Host software to emulate the controller firmware design of choice. 

The purpose of the rest af this sectian an Diagnostic Commands is 
to aquaint the casual/not-so-casual designer of Host software as to 
how to make the best use of Widget’s multiple personality 
capabilities. | , 


® 
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Read ID ::= < $0 > 


Instruction Parameter String 22 NULL 


This diagnostic command requires Widget to deviver to the host some 


device specific information. The structural layout af the data 
returned is: e 


STRUCTURE Identitiy Block 


{ this identity block is detined by the data structures contained 
Within -it; you will note, however, that a comment is given 
explaining the type of structure for a given element and range of 
bytes {€ if the entire structure is thought of as a linear array of 
bytes } that include the structure. An example is NameString ¢ first 
element to be defined below } which is a i3-character ascii string, 
and is located in brtes $8 thru $C of the returned block. 


NameString :3:= < 


1gMB_Name | 

2aMB_Name | | 

48MB Name ( 13 Brtes/888:$8C; Ascii String 3}? 
1GMB_ Name ::= < ‘“Widget-1g 2 
23MB Name ::= < “Widget-2g , 2 


4GMB_Name ::= < “Widget-44¢ 2 


DeviceType ::= “Device. Widgqet+Widget.Size+Widgqet.Type ¢ 3 Brtes-$ 


Widget. | 
System firmware will mot allow the hast ta Format, or 
Initialize _SpareTable; Diagnostic firmware will. 
Diagnostic ::= <$81> 

Firmware Revision ::= ic 2 Bytes/$igi:Slil ae. 


Capacity i:S <Cap_18 | Cap_28 | Cap_4@ ¢€ 3 Brtes/$12:¢14 3> 


Cap_18 ::= <$@g4CHe> 
Cap_28 i:= <Segr7ogd> 
~—Cap_ se oi:t 


{$41 3888> 


, ‘ a we 4 


a 6S ae ees ~~ aioe a we t . 2 _ 


BHF. 


cm 


‘ww @ 


:$0F }> 
Device Widget ::= <$88H81 (€ 2 Brtes/SAD:SHE 23> 
Widget.Size ::= <Size_18 | Size_28 | Size_4@ ¢ 1 Nibble, Byte 
its 4:4 > 2 
Size_1@ ::= <$89> 
Size 28 ::= <S19> 
~—~Size_ 48 ::= <$2H> 
Widget.Trype i::= <System | Diagnostic € 1 Nibble, Byte BF bits 
+> | 
System ::= <$80>; This refers ta the type of firmware that | 
imbedded in * 
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Cyl_18 ::= <$8@282> 
Cyl_ 24 ::= <$8292> 


Cyl1_48 ::= <$9484> 
Number _Of Heads ::= <@82 ( 1 Byte/S1?° 3> 


Number_Of_ Sectors ::= ¢ Sctr_18 | Setr_2H | Sctr_4H8 € 1 Byrte/SlA > 


Sctr_1H8 ::= <813> 
Sctr_29 ::= <$26> 
Scetr_4H8 ::= <$26> 


Number _Of Possible _Spare_Locations ::= <$88889C (€ 3 Brtes/S1B:S10 3; 
Number _Of_ Spared Blocks ::= <{€ 3 Bytes/S$1E:$29; range J..34B 3}? 


c Number _Of Bad Blocks ::= <€ 3 Byrtes/$21:$23; range G..348 }> 
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Read Controller_Status ::= <$81> 


Every time an operation completes << either successfully or 


exceptionally > Widget wil] return what I refer ta as 
Standard Status, thus allowing the Host system an opportunity to 
change it’s ‘¢low of execution based on state of the Status. 
Normally, this Standard_Status is all that is necessary to ensure 
continucus operation. In the exceptional case, or when the Host 
system is emulating the controller’s functions, additional 


information concerning the state of Widget is mandatory: without it 
the Host simply could not make an optimum choice in deciding a 
course of action. 

Controller_Status is then a means for the Host system toa 
interrogate Widget further. Each Status € with the exception of 
Abort_Status, which 1s a seperate command and is discussed later in 
this document } belongs to a homogeneous data structure: namely a 
four brte quantity containing a bit map representing the variaus 
exceptional conditions ¢€ active high >} that is available as the 
first four Brtes read from the controller upon completion of the 
current command. _ 

There are eight status’ available to the Host system. The Host 
requests a specific status by setting [Instruction_Parameter_String 
to the value corresponding to the status needed. | 


IF ¢ Instruction_Byte = Read Controller_Status ) 
THEN Instruction_Parameter_String ::= <¢ 

Standard Status | 
Last Logical Block | 
Current Seek Address | 
Current Cylinder | 
Intétnal Status | 
State Reqisters | 
Exception_Registers | 
Last _SeekK Address > 


The four byte response to each of the above status requests is of 
the form: 


Result ::= < Byte@ Byrtel Byte2 Bytes > 


AS 


S an 
a 
—Fipm_2.Seript 


Standard_Status ::= <$¢ 


Byteg ::= < 
Bit?: 
Bits: 
Bits: 
Bit4: 
* Bits: 
* Bit2: 
Biti: 
' Bits: 


Bytel i:= < 
. Bit?: 

Bq tS: 

Bits: 

Bits 

oa Bits: 
q Bit2s: 
Biti: 

Bits: 


Byte2 ::= < 
Bit?s 


B> 


Other 
Write 
C not 
{ not 


Widget Firmware Specification 


than $55 response from Host 


Buffer QverF] ow 
used 3} 
used } 


Read error 

No matching header found 
Unrecoverable servo error 
Operation Failed > 


{ not 


used 3} 


Spare Table Over Fl] ow 


5 or 
£ not 


Controller SelfTest failure 


used } 


less spare Bblac’s available 


SpareTable has been updated 
SeeK to wrong track oaccured 


Controller aborted last operatian > 


First status respanse since power-on 


Page 10 


reset 


Bité: Last Logical Block Number was out of range 
bitS:9 € not used 3} > 


Byte3 ::= ¢ 


Bit?: Read Error detected by ECC circuitry 


Bits: Read Error detected by CRC circuitry . 
BitS: Weader Timeout on 


Bitd: {€ not used } 


Bit3:8 : number of unsuccessful retries € out of 19 


read 


last read 
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ByteS ::= < $88 > 
Byte! ::= < € Most Significant Byte of Logical_Block_Number } > 
Byte2 ::= ¢ € Middie Brte of Logical _ Block Number } > 


Byte3 ::= ¢ ¢€ Least Significant Brte of Logical _ Block Number = 3 
> 


Current _Seek_ Address ::= <¢ $82 > 
By ted ::= < Most Significant Cylinder Address > 
Bytel i:= < Least Significant Cylinder Address > 
Byte2 ::= een Address > —_ | 


Byte3 ::= < Sector Address > 


Current_Cylinder ::= < $83 > 

C The Current_Cylinder differs from the Current Seek Address in 
that it is perfectly reasonable for the Servo to have placed the 
heads on anather track under certajn circumstances; for example, the 
drive may have been bumped >} 


Byted ::= < Most Significant Cylinder address >» 


Bytel s:= < Least Significant Cylinder address > 


Byte2 ::= < Most Significant Cylinder af current seek address > 
Bytes r::= ¢ Least Significant Cylinder of current seek address 


4 


ME’ 


ee 
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ed 


Internal Status ::= < $84 > 


Byte# ::= <¢ { Register: Excpt_Status. } 

Bit?: Recovery {€ active high --> Recovery ON } 
Bité: Spare almost ful] 

—~BitS: Buffer structure is contaminated 
Bit4d: Power reset has just occured 

Bits: Current Standard Status is non-zero 
Bit2:i1 3: { not used := g 3 

| BitG: Set if controller LED is lit > 


Bytel s:= < { Register: DiskStatus } 
Bit7: On_Track € heads are position where they 
should be } | 
Bité: Read a Header after Recal 
'BitS: current operation is a WRITE operation 
Bit4: Heads are parked 7 


oes 


Bits: Do sequential search of Logical Block 
7 { leok-ahead structure 
ee, _Bit2: Last commad was a multiblock command 


Biti: Seek_complete 
Bit#: Servo offset € auto } is on > 


Byte2 ::= < € Register: BlkStatus } 

: This byte of status is valid ONLY after a ProFile/Syetem 
command. If the byte is read after a Diagnostic command it 
wil] contain inftformatioan concerning the last 
nen-Diagnostic command. 

Bit’: SeekNeeded { 4 seek was needed ta arrive at 
the current Block 3 

Bité: Head Change--Needed { like Bit?, but Head 
change instead of seek } 

BitS:2 #08 € not used 3 | 

Biti: Current Block is a Bad Block 

Bit#: Curremt Block is a Spare Block > 


Bytes 1:5 < $468 € not used } > 


a 
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State Registers ::= { $05 > 


Byted :i= < $98 © not used } > 


Bytel ::= ‘ ¢ Register: Sel#Tst_Result > 


CiBit?: 
3S Bité: 
‘Bits: 
Bitds 
Bit3: 
Bit2: 
Bitis 
Bitg: 


Ram Failure 
Eprom_Failure | 
Disk_Speed_ Failure 
Servo Failure 
Sector_Count_Failure 
State_Machine_Failure 
Read Write Failure 
No_Spare_Table_ Found > 


~—Byte2 ::= ¢ € Register: Port2 } 


y Bite: 


~—Bité: 


Bits: 


Disk Read/Write direction set to Read 
servo is able to accept a command ¢ SioRdy 3 
MSell € MSel#@ and 1 determine the memory 


“source and destination } 


“Bitas: 
‘Bits: 
~ Bit2: 

Biti: 


; Bitg: 


Mselg 


=p 

CMD 

Ece .error 

State machine is running > 


Bytes ::= < € Register: Controller_Status_Port } 


Bit?: 


Bits: 


Sito: 
Bitd: 


CrcError { active low } | 
{ this bit ie valid ONLY when the 
controller state machine is NOT itn reset, 
which should be every time that this bit is 
read by the host. Therefore, if this status 
bit indicates a CrcError, then something 
has croaked. The normal way for the host to 
check if a Cre or Ecc error has occured is 
C0: examine Status: Exception_Registers 
which are dicussed below. } 


Write Not Valid € active low 3} 
{ as in Crcérror, this bit is valid only 
when the state machine is NOT in reset. The 
information expressed by this bit is 
converted into a type of ServoError, which 
is found in Status: Exceptian_Reqisters. 3} 


ServoReady 

ServoError 

€ the servo status bits listed above are 
further explained in Appendix A: Serva 
Processor Documentation. Essentially the 


two bits combine to form four possible 


Giies 


( 


no, 


og 
a ‘ 
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servo states; the normal condition is 
ServoReady AND ¢ NOT ServoError >). } 

Bite3:8 Current controller state-machine state. 
{ as in CrcError and Write_Not_Valid, these 
status bits are valid only when the state 
machine is NOT in reset, and should read 


$49 any other time. 3 


On the surface it appears that this bBbrte is of limited use for non 
real- time situations. It is, however, invaluable in trying to 
decide if the Servo Processor is healthy, wealthy, and wise. It also 
provides a means for diagnosing a sick state machine. 
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Exception_Registers ::= < $86 > 


ByteS ::= < € Register: RdStat } | 
Bit?: Read error occured on last read attempt 
Bité: Servo Error while reading | 
BitS: At least one successful read in last read 
attempt ¢ this means that Valid data is residing in 
Buffer2 } 
Bit4d: No matching header was found during last read 
attempt 
Bit3: CreError OR EccError occured during last read 
attempt | 
Bit2:8 $88 € not used } > 


{ a read attempt is defined as being the sequence of events normally 


associated with reading a single Block of data. In the case where 
the first read of a Block was invalid for some reason, AND Recovery 
is active, then the controller will automatically retry % times: 18 — 
tries total. For example, if the first read was invalid because of a Lo. 


CrcError, but the second thru tenth reads are all correct then the 
status bits that will be active are BitS, and Bit3. Correct and 
Valid data will] be both in the normal Read buffer and in Buffer2. 3} 


Bytel ::= < | 
Bit?: Error detected by ECC circuitry 
Bits: Error detected by CRC circuitry 
BitS: Header timeout 
Bitd: { noy used := g } 
Bit3:8 : Numbegn of bad retries during Jast read 
attempt > | 


€ For the above example, this status byte will contain the value $Cl 


; 


Byte2 ::= < { Register: WrStat 3} 
Bit?: Write error occured on last write attempt 
Bité: Servo Error while writing i 
BitS: At least one successful write during last 
write attempt 7 2 
Bit4: No matching header found during. Jast write 
attempt — , a, 
BitS:4-$88 € not used 0 
{ A write attempt is much the same as a read attempt in that there 
are several events that can Keep the controller from writing a Black. 
successfully - and Can be detected at the time af the attempted. 
write. If Recovery is active then the controller will first capy. 
the write buffer to Buffer2 and then retry } | | : 


Byte2 sss < Number of bad retries during last write attemnt » 
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Read Servo_Status ::= < $82 > 
Instruction_Parameter_ String ::= < 8..8 > 


This status command is used to interrogate the Servo Pracessor in 
much the same way that Read _Controller_Status is used. In fact, the 
form of the result is the same four Byte bit-mapped quantity. 

This command is of particular value to a diagnostician that is 
interested in ‘picking-about’ with the servo processor without 
dismantling Widget as a subsystem. Refer ta Appendix A: Servo 
Processor Documentation for a complete description of the various 
status’ available and their resulting bit descriptions. 


Send Servo Command ::= < #83 > 


_Instruction_Parameter_String ::= <¢ ByteY Byrtel Byrte2 Byrtes3 > 


Normally, the Host will allow the controller to manipulate the serva 
peocessor in order to perform useful { or maybe not s0 useful! 3 
work. For example, let’s suppose that the Host system wishes toa 
move the disk drive heads from one track to another. Under norma! 
operating conditions the preferred way to perform this task is toa 
use the Send Seek command { explained below }. However, the Host has 
the capability to Bypass the controller and direct the serva 
processor. indeed, the Host can issue the servo command to positian 
the Reads € via the Send_Servo_Command + sa that the seek is 
completly transparent to the controller. The implication of this 
command is that the Host can gain even more control of the system if 
it $0 chooses. 

A more complete description of the Serva Commands can be read in 
Appendix A: Servo Processor Documentation. 


Bytes ::= ¢€ S_Command + S_Directian + Hi_Magqnitude > 
S_ Command ::= < 
Offset 
Diagnostic 
DataReca|] 
FormatRecal 
Access 
Access Offset 
Home 


Offset ::= ¢ S19 > 
The Offset command allows the Host to micrastep the heads 
im either a positive or negative direction from the center 
ef the track. The Widget Firmware does nat make use of 
this feature! 1] have instead lett this to a more specific 


ae a MOF ALISRY APE ear am FRAP fF et RIIm me UR Oem! Te me ipa lites 
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and direction of the microstep are sent to the Servo, 


Processor in Byrte2. 


Diagnostic ::= ¢ $28 € this command is not implemented in the 
servo } > 


DataRecal ::= < $48 > 

DataRecal € and also FormatRecal } is used as a “Get the 
servo in a Known state’ command, and is usually sent by 
the controller during initialization time or whenever the 
servo is not “Ready”. This command places the heads over 
the first data track closest toa the inside diameter of the 
disk, within a tolerance of 3 tracks. The accepted method 
for making certain that the heads are over a Known track 
following a DataRecal is to read a header and use the 
track information located in the header to establish the 
location. 


FormatRecal ::= < $78 > 

This command is identical to the DataRecal command except 
for the track that the heads end up over upon completion: 
about 36 tracks closer to the inside diameter of the disk. 
Unlike the DataRecal command, however, the disk surface in 
this area is nat likely correctiy store Information 
written there. This command then is used to supply an 
absolute reference point when formating the drive. 


Access ::= < $808 > 
IT use the term ‘access’ and ’seek’ interchangeably within 
the context of this document. The servo Access command is 
used to position the heads a relative distance from their 


current position. The Serva Processor has no Knowledge 
cancerning absalute position and it 18 up ta the 
controller ¢€ real or emulated + ta supply the relative 
distance. This information is passed along in Bytes and 
Bytel. 
Access Offset ::= ¢ S98 > | 

The difference between an Access and an Access _Uffset is 
that the assumption is made that heads wil! position 


themselves within a “tolerable” distance af the center of 


the track with an Access command, while no such assumption 
is made with an Access_Offset command. There is same 


information written on each track of the disk ‘under’ the 


index mark. This information is used by the serve 
processor to ‘calculate’ the center of the track ¢ data 
center 3} and position. the heads accordingly. Because the 
servgq must wait for the index to arrive under the heads 


before it can read this information there is an imolied 


latency of about i rayvolution ¢ Currently 19.4 meae- 


\ 


ia 


I | 
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attached to each Access_Offset. Normally, the Widget 
controller will use the Access command for all reads, and 
the Access_Offset command for all writes. 


Home ::= < $C > 
When the heads are “Homed’ they are sent completely off 
the data surface and held in position very near the inside 
diameter crash stop. | 


S Direction ::= < Positive | Negative > 


Positive ::= ¢ $84 { move the heads toward the outside 
Giameter } > 
Negative ::= < $88 ¢€ move the heads toward the inside 
diameter } > 


Hi Magnitude ::= ¢ @..3 € move the heads a multiple of 256 
tracks } > 


Bytel i:= < Low_Magnitude i:= 8..255 > 
Hi Maginitude + Low_Maginitude, and S_Direction establish the 
relative distance the heads must mave to arrive at the target 
track. 


Byte2 ::= ¢ Oft¢eset Directian + Auto Offset Switch + Offset Magni tude 


> 


This command byte, when used with the Offset command, establishes 
the degree and direction of microstepping. 7 


Offset Direction ::= < Positive | Negative > 

Positive r:= < $88 € offset towards outside diameter 
t 2 A ee | 
Negative ::= < $88 € offset towards inside diameter 3; 

- > 

- Auto _Cftset Switch ::= ¢ ON | OFF > | 
ON ::= ¢ $48 j(¢€ turn automatic track centering oan 
without an access command 3} > OFF ::= <« $8H ¢ da nat 


auto track center on this command ?} > 
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Offset Maginitude ::= < @..32 > 


Byte ::= < Baud_Rate + Power_On_Reset > 
Baud Rate i:= < 19.5kK_Baud | 5?7.é6kK_Baud > 


The servo “comes up’ at 19.5K baud because of the 


test equipment used on it before it is integrated 
into a system. Once it is running with a cantroller, 
however, it iS run continuosly at S?.6kK baud. This 


parameter is also a bit misleading in that once the 
servaqo has been told to go to 37.6kK it will forever 
more ignore this parameter: in other words it i864 
impossible to go from the higher baud rate to the 
lower without reseting the servo processor. 


1?.5K_ Baud ::= ¢ $89 > 
37.6 Baud ::= ¢ $88 > 


Power On_Reset ::= < $48 > 
This is one of three way to reset the servo 


processor {€ such variety! }. The other two are: 
12 Power switch, and 2) have the conmtraller pull 
on the servo reset line. Out of all three 
methods, choice two is the mast preferable iin 
that the controller will completely initialize 
all the drive parameters related ta the servo as 
4 well as automatically goto the higher baud 


rate, 
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Send Seek s:= ¢ $84 > 


Instruction_Parameter_String ::= < HiCy] LoCyl Head Sector > 


Widget’s Send Seek command allows the Host system to place the 
heads over any track on the disk. The value ot the seek address 
sent in the parameter string is used read/write a Block of data 
using the diagnostic commands for those functions. For example, 
for the Host ta read Cylinder’ 1, Head WY, Sector 18 a 
Seek Command would be issued for that combination of cylinder, 
head, and sector ¢ $9881 68 12 3 followed By a Diag_Read ¢ 
explained below >. 
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Send_Restore ::= < $85 > 
Restore Data ::= < $48 > 
Restore Format ::= < $72 > 


The Send_Restore command is used by the host to initialize the 
servo processor and to put the heads in a Known location. This 
command is the same as performing a Data/Format Recall except 
that the controller updates it’s internal state toa account for 
the new servo position ¢ as opposed to using the 
Send _Servo_Command, which is transparent to the controller }. 
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Set Recovery ::= < $86 > 


Instruction_Parameter_String ::= < ON | OFF > 


To the best of my ability I have attempted to make the 
exception handling characteristics of Widget a binary set: 
either Widget handles everything, or the Host system does. The 
command Set Recovery is the Host’s link with this all or 
nothing world in that it is through this instruction that the 
Host can gain control of the media. When Widget comes up after 
being reset it assumes control and sets Recovery to be ON. The 
Host system must overtiy change this state € via Set _ Recovery } 
if it wishes to emulate a different exceptian handling 
criteria. Once Recovery is OFF, the controller wil! always fail 
in an operation if an exception occurs: the Host system MUST 
assume responsibility for ALL error handling. 
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Soft _Reset ::= < $97 > 
Instruction_Parameter_String ::= <« NULL > 


This commands instructs the Widget firmware to restart it’s 
flow of execution at it’s initialization point. The results 
should be the same { from a software point-of-view ? as a 
power-reset. 


Page 
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Instruction_Parameter_String ::= <« NULL > 


When the Host issues a Send Park command to the controller the 
results are that that the heads are moved off the data surface 
and held very near the inside diameter crash stop. The 
difference between this command and the Send_Servo_Command: 
Home is that Home is performed ‘open-loop’ with the crachi stop 
aS it’s reference point, while Send_Park is am access command 
to a specific track. The net result is a fairly hefty saving of 


time: the access command can be an order of magnitude quicker 
than Home/Recal. 
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Diag Read ::= < $89 > 
Instruction _Parameter_ String ::= ¢ NULL > 


The Diag Read command is used to read the Block on the disk 
painted to By the last seek address. This instruction is valid. 
for states that the controller might be in: it is advised that 
a Send Seek command precede the Read. The form of the returned 
data is exactly the same as that of ProFile Read or a Sys_Read 
in that 4 Bytes of Standard Status precede the block of data. 


Diag ReadHeader ::= < $HA >. 


Instruction_Parameter_String ::= < Sector ¢ $8..%$12 } > 
When the heads are positioned over an unknown location, or when nN 
it iS suspected that a block’s header is shot, it is time ta 
use the Diag ReadHeader command. This instruction allows the | 
host to “suck-up’ both whatever information is residing in the 
Bblock’s header field as well as the data from that block. The 


form of the result is: 


Result s:= ¢ 
< Standard_Status/$9#g:$G3 > 
< Header /S84:S09 > 
< Gap/SgA: Sar > 
< Syne/$lgisil > 
< Data/$i2.. > ? 
Standard Status ::= < €.as defined above } > 
Header ::= ¢ HiCyl LoCyl HdSct -HiCy! -LoCy! -HdSct > | 
HiCy] ::= ¢ 1 Byte, Most significant cylinder address 
5 | 
LoCy] r= << 1 Brte, Least significant crlinder 


{ 1 Byte, bits?7:46 are head address, bitsd:f8 


Hosct = = 
are sector address 7 ‘> 
-HiCyl r:= < Ones-complement of HiCcyl > 
~Loty| r= < Snoeecene owen oe ce > 
-HdSct = < Ones-complement of ndSct > 


_ 


35. | 
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Gap ::= < 3 brtes of $88 > 


Sync ::= << $9190 > 
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Diag Write ::= < $8B > 
Instruction_Parameter_String ::= < NULL > 


This instruction allows the host to write a block of data to 
the location on disk pointed to Br the last seek address. 
Diag: Write is valid for all states that the controller may wind 
up in, But it is rmecommended that a Send_Seek command precede 
the write command to ensure that the correct block will be 
written. 


ooo 
re . 
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Store_Map ::= < $8C > 


Instruction_Parameter_ String ::= < NULL > 


i sad = s 


© 


The Store _Map command is to be used by the Host to lagically 
re-interleave Widget. Widget will be used on a number of target 


hosts, each of which would like to optimize the pertormance ¢€ 
sequential } of the disk drive. This optomization can occur in 
one of two ways: 1) either seperate lines are set up in 
manufacturing to initialize Widgets specifically for each 
target host or 2) we can manufacture a single Widget unit and 
have the Hast initialize the drive for it’s specific 


requirements. 


Included in the SpareTable structure is a data structure called 


the InterLeave Map. This map is used as another level of 
logical addressing during the calculation of a cylinder, head, 
and sector address from a given logical block address. 


Specifically stated, once a sector address has been determinied 
it is used as an index into the InterLleave_ Map and a new sector 


address is generated ¢ the InterlLeave Map is an array with the 
same number of entries as there are sectors, and each entry 
must be unique and valued within the range of legal sector 


Values }., 


Tt is extremely important that the host system proceed with 
caution when changing the Map. A remapping of the elements 
Within the SpareTable is REQUIRED with every change to the Map 


«{ this is because as the sectors are logically remapped the 
defects that stay with a physical address move araund relative 
to a logical Block’s number }. For this reason I suqgest that 
all changes to the map be done using the Write _SpareTable 
command in conjunction with a remapping of all the spare/bBad 
Blocks, 3 

This command is externally executed ¢ br the host +? as a write 
command. The first Number_Of_ Sectors worth of data in the 


buffer are assumed to be the new map. 


ne 
cs] 
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Read SpareTable ::= ¢ $4D > .. 


Instruction Parameter String r:= < NULL > 


Reading € and writing } Widget’s spare table is an absolute must for 


diagnostic purposes, and if the Host wishes to emulate 


controller. The result of this instruction is identical 


performing a ProFile_Read from block SFFFFFE and has the form: 


23= ¢ 


Result 
« Standard Status/$69:$03 { as defined above } > 
< Fence/$949:8087 > 
< RunNumber/$#8:$0B > 
{< Format_Offset/$dC > 
< Format_InterLeave/tdgD > 
< HeadPtr_Array/SZE:$8D > 
< SpareCount/$SE > 
< BadBlockCount/$8F > 
< Bi tMap/$S8A:$93 > 
{< Heap/$?4:$1C3 > 
< Interleave Map/$iC4:$1D7 > 
< CheckSum/$1D8:S1D9 > 
{< Fence/#iDA:$1DD > » 


Fence ::= ¢€ ¢« SFA > <¢ $78 > < $30 > ¢ SIE > 5 


Morevumber ::= ¢ S2-bit interger > 


The RunNumber is incremented each time the spare table 


the 
to 


is 


writen to the disk. Because two copies are Kept an the 


disk, the RunNumber is used to decide which is the 


nmofase 


recent of the two should both copies of the table nat be 


updated. 


Farmat Offset ::= < $49..NumberOQfSectoars > 
Format Offset is the number of physical sectors there 
from index mark until logical sector @. 


ta the current logical Block mumber. 
Ptr s:m % BHW..B7F > 


are 


Format_InterLeave ::= <¢ $80..886 > 
This mumber is the interleave facter for this disk and is 
used in calculating where each of the logical sectors are 
im terms of actual physical sectors. 
. HeadPtr_Array ::= < ARRAY &..127 1 of HeadPtr > 
HeadPtr ::= < Nil + Ptr > 
Nil ss= < $89 | $88 > 
Le a HeadPtr is Nil,. then there is na 
linked-list structure in the heap corresponding 


~ 
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A Ptr iS a seven bit data structure that 
“points” to a specific location within the Heap 
C if the Heap can be though of as a linear array 
of bytes, the a Ptr is used toa index into that 
array }. To arrive at the actual index value 
within the Heap, the Ptr must first be 
multiplied by four. 


When a disk is formatted and fresh data is being written to it, 
each logical Block is assigned the first available physica! 
block on the disk. Therefore you would expect that 
LogicalBlock¢ 8 >) would occupy PhysicalBlockt 9 2, L¢1>2 -—> 
PC1>, etc. There are instances, however, when a block of data 
must be relocated to another space on the disk that does not 
follow the original progression ¢ for example, the original 
space was defective }. In order to ‘find’ these relocated 
blocks in the future a record must be Kept as to where all 
these relocated blocks have been put. This record takes the ‘/ 
form of 128 linked lists having the form HeadPtr(¢n) --> ned 
LinkedList(n), where n := §..127. The algorithm for deciding 
whether or not a LogicalBlock has been relocated is to extract 
bits 16:18 from the LogicalBlockNumber and use it as an index 
imto the HeadPtr_Array. If the HeadPtr associated with this 
index value is Nil then LogicalBlock has not been relocated 
else use HeadPtr.Ptr to search the linked list corresponding to 
this HeadPtr value. Now to decide if the LogicalBlock has been 
relocated a test must be made as the linked list is traversed 
by comparing the LogicalBlockNumber’s bits %:8 to the current 
list element’s token value. If they match then LogicalBlock has 
been relocated and it’s new position is a multiple of the Jlist 
element’s position in the Heap. | 


eter 


SpareCount ::= <¢ $09..$4C > 
BadBlockCount ::= < $48.,.¢4C > 


BitMap ::= < ARRAY @..34B J] of Bits > | 
The Bit map is used ta Keep a record af which spare blacks 
are occupied, and their locations on the disk. 


Heap ::= < ARRAYE §..$48 ] of ListElement > 


ListElement ::= <¢ _ | a 
| | © Nil+tUsedtUseablet+Sor_TypetData_Type + eo 
< Token > | 


< Ptr + 3 
Nil ris < $88 € IF Nil THEN End_Of Chain } > 
Used ::= < $46 > | | | 
Useable ::= < $29 > 


a. * | 
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Spare ::= < $18 > 


BadBlock ::= < $88 > 

Data_Type ::= ¢ Data | SoareTable > 
Data ::= < $82 > | 
SoareTable ::= < $98 > 


Token ::= < Bits?:8 of the LogicalBlockNumber > 
InterLeave Map ::= < ARRAY [8..NbrSctrs] OF &..NbrSctrs > 


CheckSum ::= < the sum of all brtes in the spare table from the 
first fence to the end of the heap, in MOD-65536 arithmetic > 


Ai, 
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Write Spare_Table ::= <. $@E > 
Instruction _Parameter_String ::= ¢ < $FH > ¢ $78 > < $30 > < S1E > > 


‘This command allows the Host to ‘force’ a new spare table on 
the controller, and is executed just Jike- any of the other 
weijte commands {€ the data in this case MUST conform to the 
structure presented in Read_SpareTable +. The data sent to the 
controller is written to the two spare table locations on the 
disk. 


q Firm_4.Script 
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Format Track ::= < S8F > 
Instruction_Parameter_ String ::= ¢ 


< Format_Offset > 
{ Format_InterLeave > 
< PassWord > 


Format_Offset ::= < $48..Number_Of Sectors > 


This parameter dictates which sector { beginning with 
sector# - the first physical sector after index mark } 
Will be logical sector 9 for that track, 


Format _InterLeave ::= < $68..$86 € interleave factor } > 


PassWord 


::= € << SFB > << $78 > <¢ $30 > < SIE > )D 


The format command is used to: 


1. Operate on the track that is currently beneath the 
heads - this implies that the Host had best perform a 
Send Seek command prior to formatting a track. 


2. AC erase the entire track - this implies that all 
Gata stored on this track has acheived Nirvana and 
are living happlily ever after in the great bit 


bucket in the sky. 


3. New headers wil] be layed down an EVERY sector of 
the track. 


Firm_4.script 


Instruction_Parameter_String 


Initialize_SpareTable ::= < $19 > 


Format_Offset ::= < $88..Number_Of_Sectors > 


Format_InterLeave ::= < $48..¢86 ¢ 


PassWord ::= ¢€ «¢ $F > < $78 
This command form the Host 
the slate clean’ as far as 
Imitialized table is written 


‘) 
ny 
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< Format_Offset > 
< Format_InterLeave > 


< PassWord > 


interleave factor 3} > 


> < $30 > < SIE > ) 


instructs the 
the SpareTable 
to disk. 


controller to 
iS concerned. 


“wipe 
The 


wig 
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Read _Abort_Status ::= < $11 > 


Instruction_Parameter_String ::= < NULL > 


Read Abort Status Will return valid data oanly AFTER’ the 
controller has aborted { identified by 
Standard Status.Byrtel.Bitd -3. The form of the result is a 
sixteen Byte string, and the contents are the contents of the 
controller’s registers at the time of the abort - with the 
exception of Bytes $HE and S8F, which constitute the return 
address of the procedure that called the Abort routine. Because 
all of the information that can be derived from this request 
from is extremely firmware dependent an appendix { Appendix C: 
Abort Status Variables + has been created that hopefully will 
be updated with each firmware release. 3 
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Reset _ Servo ::= < $12 > 
Instruction_Parameter_String ::= < NULL > 


Reset. Serva allows the host to initialize the servo processor 
without having to power the device down. The controller wil] 
automatically reset the Servo, check for valid imitial 
conditions and perform a Data_Recal. 


—. 
\, 


ei 
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Instruction _Parameter_String ::= < NULL > 


The Scan command causes the Widget to read all blocks that are 
with the range of blocks set aside for user data blocks. If any 
of these blocks are bad then the block will either be relocated 
{ if the data can be recovered } or marked as bad and relocated 
on the next write to that Block. The SpareTable can be examined 


before and after a Scan command find the locations of al} bad 
blocks. | 


2” 
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SYSTEM_COMMANDS 
System_Commands have been implemented for essentially two reasons: 
i. I felt that it was important for Widget to add one more check on 
the CMD/BSY handshake: namely the addition of a checkbyte following 


the command string. 


2. In order to increase the performance of the system without 
modifying the hardware it was critical to introduce anather level of 


parallelism into the Host/Cantroller interface. Most € 68% or 
greater } of the reads for a specific Block on the disk are followed 
by a read for the logically sequential biock. In fact, in the 


extreme case of Lisa, this percentage is almost 188%. Therefore I 
have suppressed the command decoding for al) but the first block 
read { over aosmall range }. The implementation, then, for this 
added parallelism is to send an additional parameter with the ¢ 
first + LogicalBlock indicating the number of blocks to be read. | 
This implementation holds for Reads and Writes, but not “for eA 
WreiteVerifies. I have taken the liberty of .assuming ¢ hopefully : 
correctly 3 that WriteVerifies do not exhibit the same 
characteristic behaviour as the other two types of commands, and 

that they are fairly long commands to begin with. The trade-off then 

Was one of saving code space {€ a Sys_WrVer is the same routine as a 
Pro_WrVer, but with command checkbyting } vs. adding a third 
multiblock function with limited performance increases. 


The protocol for System commands is slightly different then that of 
Profile commands. In the case of a Read command, each block of data 
is transtered to the host when it received by the controller: there 
is NO buffering of disk blocks on Widget at this time. The transter 
looks just like ather read-style transfers in that Standard Status 
iS sent with the data block and the data block is the same length ¢ 
232 bytes 3. Instead, however, of responding with the basic 
“Controller is ready for command’ response when the Host sets CMD ¢ 
atter storing the data block } the controller will respond with 4a 
“Controller ready to get next block’ response. 
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Sys Read ::= < $88 > 


Instruction _Parameter_String ::= ¢ <¢ Black Count > < LogicalBlock > 
) | 


Block Count ::= < $81..%13 > 
This parameter is the number of Blocks to be read that 
follow sequentially from LogicalBlock. It is assumed that 
one block € LogicalBlock 3} will be read, making the 
Block Count the number of Blocks following the first one 
that is to be read, also. 


LogicalBlock ::= < L_1SMB 1 L_29MB | L_4aMB > 
L_19MB ::= < $@990908..$0048FF > 
L_28MB ::= < $889990..$9997FF > 
L_48MB ::= < $989G09..$012FFF > 
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Meco 


Sys_Write ::= <¢ $81 > 


Instruction_Parameter_String ::= ra Block Count > <« Logical Black > 
) 


Block Count ::= ¢ $81..$13 >— 


LogicalBlock ::= < L_1ZMB | L_29MB | L_48MB > 


L_1gMB ::= < $888800..$8G4BFF > 
L_28MB ::= < $@9G9888..¢0097FF > 
L_48MB ::= < $G99908..$012FFF > | 


Sys_wrVer t:= < $82 > 


Instruction _Parameter_String ::= ¢ LogicalBlock > 


LogicalBlock ::= < L_1gMB | L_29MB | L_4aMB > oe 
L_19MB ::= ( $@88000..8004BFF > . * Aap 
L_28MB ::= < $890098..$0B97FF > | 


L_49MB ::= ¢ $808808..$0812FFF > 


oes | : 
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HANDSHAKE PROTOCOL 


Both Widget and ProFile share the same Host interface scheme, and 
therefore a lot in common when it comes to trying to communicate 
with the Host system. ProFile’s protocol is documented in “ProFile 
Communication Protocol’, and a follow-up document titied ‘The 
Extended ProFile Protocol’ written by Karl Young is available for 
more detail. 


The actual sequence of events can be portayved as follows: 


Protocol Sequence ::= ¢ 

< Initial HWandShake > 
Command _DownLoad > 
Response _HandShake > 
Data_Received Handshake ] 
Final _ HandShake > ) 


nN OIN AN 


Initial_HandShake :3= 
1. Host asserts CMD, sets data direction to read 
2. Controller asynchronously responds by: 
a. Writing $81 to the Host 
b. ASSerting BSY 


3. If the Host recognizes the controller response, it will 
respond by: 

a. Writing a $55 to the controller 

b. Otherwise it will write a SAA 

c. In either case the Hast will de-assert CMD. 


4. The controller will respond to the Host By: 

a. In either case € whether the Host responded with a 
$55 or $AR or anything else } the controller will 
eventually end up waiting for the next instance ot 
CMO: 

b. If the response was a $55 then the cantroller will 
De a ‘captive’ audience, anxiously awaiting 
imstructions trom the Host as ta what ta do next. 

c. Otherwise, the controller will Abort, and leave 
Standard Status saying $0 in it’s buffer where the 
host can read it. The state of the command sequence 
for the controller then becomes [Initial Handshake, 


( and the Host should read do it’s best ta read the 
ai | Standard Status as soqon as it motices that hie 
handshake sequence has been changed. The execption ta 
thie “Otherwise” is when the response from the Host 


is a FreeProcess response ¢ explained below }. 


Cammand DownLlaad ::= 
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1. The Host writes a variable length string of hex brtes 


to the controller. The address of where these bytes are 
sent is set up By the controller in the Initial_HandShake 
phase. The length of the hex string is up to the Host, but 
is imtended to be the length of a command string ¢ indeed, 
the string of Bytes is supposed to be a command string! }. 
The controller Knows to increment it’s address counter ¢ 
remember, it is responsible for loading the string into 
it’s memory 3 bBy a falling edge of STROBE from the 
interface card. 


Response _HandShake ::= 
1. The Host asserts CMD 


2. The controller responds asynchronously by first reading 
it’s Buffer in the locations that it set aside for the 
Host to perform it’s command download, doing what is 
necessary to decode the command ( i.e., validating the 
checkByte, making certain that the command was af the 
right type, and decoding the command }. It then writes a 
response brte to the Host which has the value of ¢ 
instruction Syte + 23. 


3. The controller asserts BSY 
4. € look at 3. for Initial HandShake 3 
3. If the controller receives a $55 then it will continue 
executing the command, atherwise it will Abort and return to 
Initial HandShake. 
Data_Received_HandShake i: 
1. If the controller is expecting data € as is the case 
for awrite command } then in the Response_HandShake it 
Will de-assert BSY and wait for the next occurance of CMD. 
2. When the Host “sees” BSY Become de-asserted it wits 
then write as much data as if pleases € Jike the command 
download, the contraller dictates the address af the data 
while the Host dictates the length >}. 
3. The Host the asserts CMD 


4, The controller responds asynchronously to the Host by 
writing a #96 ta the Host. 


5S. The controller then asserts BSY 


Ay 


ipsa’ 
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6. Assuming the Host accepts the response from the 
controller, it will respond by writing $55 back to the 
controller and then de-asserting CMD. 


7. jhe controller will then continue executing the 
command. : 


Final _HandShake ::= 


1. When the controller finishes with the execution of the 
instruction, | | | 

it will put the latest Standard Status in a location in 
it’s buffer 

where it will be accessible to the Host <¢ as well as 
any data that 

might be a result of the command executian }. 


2. The controller then de-asserts BSY 


3. The Host detects that BSY has been de-asserted and then 
reads from the controller as many brtes as it wishes ¢€ in 
much the same fashion as it does when writing a command 
String to the controller: the controller points toa the 
Gata and the Host moves it 3. : 


There is € at least } one implication to this protocol: the Host is 
capable of tying up {98% of the controller’s resources if it sa 
chooses. This is Becauge the controller has no way of Knowing when 
the Host has finished reading/writing from/to it’s data buffer. 
There needs, therefore, to be a mechanism for the Host ta let the 
controller Know that it has freed up the controllier’s resources. 
This mechanism € for Jack of a better mame } is called the 
FreePracess. The Host communicates the FreeProcess ta the controalie 
in either of two ways: 1) the ProFile way, and 2) the Widget way. 


ProFile FreePracess ::= 


1. The Host downloads a commands of < $F8 > ta the 
controller. | a | 


oo ral The cantroller decodes the command and enters 
qc FreeProcess. —- 


bWiidqet FreeProcess i:= 


© 
~y 


1. During the Initial _HandShake ¢ when the controll | 
attempting to let the Hast Know that it is ready for a new 
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command 3} the Host responds to the $81 with a $69. 


2. The controller responds to the reception of a $69 
instead of $55 br entering FreeProcess. Al] further — 
handshaking is terminated.” | | 


a 
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COMMAND SUMMARY 


ProFile Commands: 


ProFile Read ::= ¢( <$98> < 3 bytes LogicalBlock > > 
ProFile Write ::= ¢€ <$@#1> < 3 Brtes LogicalBlock > ) 
ProFile WrVerifty ::= ¢€ <$82> ¢ 3 Bytes LogicalBlock > ) 


Diagnostic Commands: 


Read_ID ::= ¢€ <$12> <$8H> <SED? 9 7 

Read Controller_Status ::= ¢ <$13> <$H1> ¢ Status > < CheckByte > 
? 

Read Servo_Status :: 
send_Servo_Command : 
CheckByte > >) 

Send Seek i: ¢€¢ <$16> <$84> << 4 bBrtes cyl/head/sector > < 
CheckByte > > 

Send Restore ::= ¢ <$13> <$85> < Data/Format Recal > ¢ CheckByte > 
2 

Set_ Recovery 
Soft Reset : 


C <$13> <$82> < Status > ¢< CheckByte > 2 
¢ <S$146> <S$HB3> < 4 command byrtes > < 


C <$13> <$86> < On/OFF > < CheckByte > ? 

: <SL2> <SO7> <SES6> | 

Send Park ::= <$12> <$88> <SES> 9 

Diag Read ::= C$l2> <BHP> <SE4D 9 

Diag _ReadHeader ::= ¢ <$13> <SMA> < Sector > < CheckByte > ») 
Diag_Write i::= € <$12> <$MB> <SE2> ) 


“NN 


Store Map ::= ¢ <$12> <$8C> < SEL > )D 

Read SpareTable ::= € <$12> <$@D> <SEM> dD 

Write SpareTable ::= ¢( <$16> <$HE> < PassWord > < CheckByte > ) 
Format Track :3= ¢ C$13> <SOF > 


<Offset><InterLlLeave><PassWord><CheckBrte> ) 

Initialize_SpareTable ::= 
C <S$i 46> <BlLH> < Offset >» < InterLleave> < FassWord > < 
CheckByte > >? 


Read Abort stat ::= ¢ <$12> <B11> <$DC> > 
Reset Servo ::= ¢ <$12> <$12> <$DB> 3 


Scan ::= ¢ <$iL2> <$i13> <S$OA> 9D 


System Commands: 


Cc 


Sye_ Read ::= | poeta 7 
C <$26>  <$88> ¢ Biktnt > ¢ 3S Bytes LagicalBlack > < 
CheckBrte > ») 7 3 


Sys_Write i: | 
C CS$26> <BH1L> ¢ Bilkent > © 3S Bytes LogicalBlock > < 
CheckByte > 3 | 


oys_WrVerify i:= ¢€ <$25> <$82> << 3S OBrtes LagicalBlack > 
CheckByrte > ) | : 


Firm_S.Sceript 
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Exception Handling: 


Widget has been designed torun fault free for most of it’s 


operating time. This means that almost every single time that a 


request is made of the controller it will be performed flawlessly. 


However, there are some exceptional cases —- most fall into the 
category of extreme errors- where the controller must attempt ta 
correct a problem. The most likely to occur is either when the drive 


is externally ‘bumped’ and the heads are forced off track, or flaky 
block is read ¢ erc/ecc error }. , 


SERVO EXCEPTIONS 
It is possible for the Servo Processor to detect that the heads 


have gone off track. When this occurs the Servo will attempt to put 
the heads back on track transparently to the controller. There are 


three outcomes to this exception: 


1. The Servo will put the heads back on the correct track and 
all will be well with the world. 
2. The Servo will mistakenly put the heads on a track that is 


close to the target track. In this case the controller will 
detect a header mismatch the next time it reads a block on the 
disk and will issue a seek to correct the pasition error. 


3. The Servo will raise ServoError € a gross misalignment 
detected + and drop ServoReady in which case the controller 
Will have no choice but to issue a DataRecal to clear the 
ServoError, then issue a seek to get back to the target track. 


Firm_6.Script Widget Firmware Specification .  ~ Page 48 


READ/WRITE EXCEPTIONS 


There are occasions when the a spot on the disk surface becomes 


unuseable, or for some reason causes the data stored in that area toa 
change. To handie this type of exception Widget is equiped with 2 
error detecting devices and 1! error correcting device { although Ecc 
is both error detecting and error correcting }. Widget uses a 
sixteen-bit cre polynomial € CRC-16 3 to detect all single-burst 


errors less than sixteen bits in length, almost all single-burst 
errors of sixteen bits, and most single-burst errors greater than 
sixteen bits in length. A 48-bit ecc polynomial is also used that 
has error detecting properties similar to that of the cre 


polynomial, except that it handles burst of up to 48 bits. It can 
also correct single-error bursts up to twelve bits in length. 


When a Block read, if the first read is successful { no errors } 


then the data is transfered ta the Host, thus completing it’s 
command, Suppose, however, that the Block is not read successfully 
the first time. The causes of this exception are 4: 
1. Servo Error: this execption is handled by leaving the read 
routine and getting in touch with the Servo Processor to see if 
things can be straightened out. Once the controller is 
convinced that the Servo is well and that the heads are 


positioned where thye should be, it retries the read. 


a. the state machine indicates. that it is in the wrong ending 
state. This is considered a catastraphic exception an the 
controller will abort. 


3. The state machine indicates that a matching header was not 
found. Before making this decision the state machine searches 
the track twice for amatch header. To handle this exception 
the controller reads a header from the track that the heads are 
currentiy positioned over and tries toa determine if the heads 
are positioned correctly. If they are, then it is assumed that 
target Block’s header is faulty and the track will be spared. 
If no header can be read from the track it can be determined if 


the heads are positioned correctly or if all headers on the 
track ane. shot. In this case the controller will issue a data 
recal “and seek back ta the target location and retry. If a 
header still can not be found the Bleck will be spared. 


4. The state machine indicates that a cre oar ecc error has 


occured. The controller will automatically retry--SE times ( a 


tatal of 18 reads 3}. lf a successful read is encountered during 


this retry sessian the controlier will save the valid data. At. 


the end of all the retries, if the nmumber of bad reads wae 2 ar 
Jess then the block is transfered to the Host. If the number is 
between 2 and 18 then the data is stil) returned ta the Host. 


‘ / 
\y 
“ 4 a“ 


Ms, ra 
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but the controller goes Back to the target Block and performs a 
WriteVerify with the valid data; if the block fails the verify 
then it is spared. If the number of bad reads is 18 then the 
ecc correction algorithm is applied to the result of the Jlast 
retry. If the data is correctable then it is returned to the 
Host; the target block is then write verified with the valid 
data and if it fails it is spared. If the data is 
uncorrectable, then undefined data is returned to the Host ¢ if 
it chooses to read it } and Standard Status indicates that the 
operation failed. The target block is then declared a BadBlock 
{ a form of spare }. 


BadBliocks have the property that when they are read the 


controller will attempt to extract the data from the target 
block and performing exactly the same steps as in a normal read 
im an attempt to recover the data. When they are written to, 
the controller performs a write verify to the target block. If 
the Block passes the verifyu then it is no longer a BadBiock, 
otherwise it is spared. 


SpareBlocks have the property that they are ‘relocated’ 


logicalblacks. In other words, SpareBlocks are blocks on the 
disk that are transparent to the Host and were set aside for 
the explicit purpose of relocating faulty Blocks. There are (76 
such SpareBlocks on each Widget, spaced 254 blocks apart on a 
1SMB drive, Siz2 blocks apart on a ZEMB drive, and 1824 blocks 
apart on the 48MB drive. When I decided upon this sparing 
algorithm |! chose a trade-off tetween overall performance and 
Gata security. 


When a Block is spared, it is relocated to the nearest available 


spare block so that the time to get to it is minimized. This 
works only as long as spared blocks are more or less unitorm 
over the entire disk surface. On? the other hand, if the ideal 
case were to be-simplemented «© the controller Keeping track of 
which Blecks on the disk were unused and relocating to the 
nearest ane 3 the space needed to contain the data structure 
that Kept track of the algporithm would be enormous. The 
decision ta Keep the structure contained inside oat one data 
bleck € Si2 brtes 3} led to the ’checker-btoard’ algorithm that 
has been tmplemented on Widget. 
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| MISCELLANEOUS 
Parking: 


Toa quard against any mishaps when power is shut off to Widget, 
there is a mechanism in the firmware that takes the heads off 
the data area of the disk after a period of idleness. This 
mechanism is Known as ’parking’. Unfortunately, it is possible 
for parking to synchronize with periodic uses of the drive by 
the Host, causing a mild form of thrashing brought about by the 
constant seeking needed to move the heads between the park 
position and the target position. It was determined 
empirically on ProFile that a gocd compromise delay time to 
park is 3 seconds and that time hold for Widget. 


Arm_Sweep: 


To protect the head-arm bearings from too many short seeks ¢ 
this causes a possible migration of lubrication away from the 
surfaces that are meant to be lubricated } the arm is swept the 
complete width of the disk data surface every 29498 seeks. 


Self Test: 


When the controller comes up from being reset it performs the 
following selftest functions: 


1. Register Test 
Write and verify one’s and zero’z to all registers; 
halt if failure 

2. Stack Test | 
Check push/pop, call/return capabilities; halt if 
failure = 

3. Ram Test , 
Write ones and zeros toa all ram Jacations; don’t 
allow ProFile or System commands if failure. 

4. Eprom Test . 
Check external eprom banks # and i for check byte; 
don’t allow ProFile or System commands if failure. 

3. Motor Speed 

Check time from index toa index; don’t allaw ProFile 

or System commands if failure. | 


~* 


6. Track Count 
Seek from the format recal pesitian to track 8. This . 
test fails if the servo is unable to complete this 


task, 


?. Spare Table 
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Find both spare tables and write verify them; don’t 
allow ProFile or. System commands if failure. 


8. Read/Write Test 


Widget performs a read/write test on a track nat used 
for data. If a failure occurs on all Blocks of that 
track then the controller assumes that either the 
Gdisk or the read/write channel is unusable. . 
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APPENDIX C: Abort_Status_Vari ables 


There are occasions when the Widget controller will detect that 
something is radically wrong with the Widget subsystem, i.e., the 
ram on-board the controller goes oan vacation, or the state machine 
gives up the ghost, etc. In one of these cases the controller will 
“abor t*% it’s current instruction and return cantrol to the Host, 
hopefully with enough information that the Host can make = an 
intelligent decision concerning the state af the Widget. 


The Host can read in some information concerning the abort that the 
controller took br read Last_Abort_Status. This command returns a 
result that is 28 Bbrtes long: 4 bytes of Standard Status followed by 
16 Bytes of abort status. The contents of the 16 Bbrte result is 
dependent upon the abort taken, and is determined by examining the 
contents of the 15th and iséth bytes which are apointer into the 
ees where the abort occured. 


In the following list the contents of brtes 15 and 16 are indicated 


€ as a hexadecimal 16-bit integer, just as you would read them from. 


the Butter: byte 15 most significant... 3}, with a brief descriptian 
of th ereason why the abort was taken as well as any comments 
concerning other bytes -of immediate interest included within the 


Abort _ Status structure. 


$S$HZEA: Tllegal interface response, or Hast Nak 
Byted?: Response Brte received from Host 
$H83BS: Tlleqal Ram_Bank select ~ 
Byte#@: Bank number of attempted select 
$4487: Format Error: Illegal State_Machine State 
| BytedA: State of State Machine at time of failure 
$O4CB: Il]lleqal Bank_Switch: Either call or return 
oe Byteg@: Bank number of attempted bank select 
$8513: I[llegal Interrupt or Dead Man_Timecut 
, BytedA:08 : Address of routine at time of timeout 
S$iiMi: Format Error: Error while writing sector 
Byte@?: Error Status from FormatBlock 
SLLlEA: Command CheckByte Error 
Sle203: ProFile or System command attempted while SelfTest error 
$l217: Tlleqal Interface instructian 
SlS1i: Unrecoverable Servo &cror while reading 
SISES: Sparing attempted. an nan-existent spared black 
$1513: Sparing attempted while spare table full | 
SBiSeD: Deletion attempted of nan-existent bad block 
$1664: L)llaegal exception instruction 


+1 O41G@, Bis ae Ue ates ie ate HON si gage aa” ete eae ea a on eR Ba gs di AO age ye 


SU? 


— 


$iBgi: 
$iBS6: 


$1BAB: 


$1BO2: 
$icis: 
$1C24: 


$1C7S: 
$SiCFF: 
SLE4A;: 


$1 F2F: 
' $2021: 


teres: 


$23/7C: 
$2493: 
$24B3: 
$2522 


$2465E: 
$2688: 
$2°7ELR: 


$2ALG: 
$2013: 
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Servo Status request sent as Servo Command 
Restore Error: Non-Recal parameter 
Byteff: Illegal parameter sent 
Store Map Error: Parameter larger then the number of sectors 
BytegA: Tlleqal parameter sent : 
Illegal password sent for Write Spare Table command 
Illegal password sent for Format command 
lllegal format parameters 
ByteS9: Offset parameter 
Byte#A: interleave paramter 
lllegal password sent for Initialize _Spare_Table command 
2ero block count sent for MultiBlock transfer 
Write Error: Illegal State Machine state 
BytefA: State Machine state at time of error 
Read Error: Illegal State_Machine state 
BytedA: State Machine state at time of error 
ReadHeader Error: Illegal State_Machine state 
BytedA: State Machine state at time of error 
Request for illegal logical block 
BytedC: High brte of requested logical black 
Byted#C: Middle brte of requested logical block 
BytedC: Low Byte of requested logical block 
Search for SpareTable failed 
No SpareTable structure found in SpareTable 
UpDate of SpareTable failed 
Tllegal SpareCount instruction 
Bytedg?: Value of illegal instruction 
Unrecoverable Servo Error while performing overlapped seek 
Unrecoverable Servo Error while seeking 
servo Error after Servo Reset 
ByteWA: Value of controller status port at time of error 
Serva Communication error after Servo Reset 
Scan attempted without SpareTable 


I. 


— AWEUIx A 


WIDGET SERVO FUNCTIONAL OBJECTIVE 


BASIC SERVO FUNCTIONS 


Widget servo control functions are handled by a 28 microprocessor. The 
Z8 handles all I/O operations, timing operations and communication with a 
host controller. Control functions to the Z8 Servo Controller are made 
through the serial I/0.. | 


The following commands for the Widget servo are: 


Ae 


Be 


he 


G. 


HOME - not detented, heads off data zones located at the inner stop. 
RECAL ~- detented at one of two positions. 


Ll. FORMAT RECAL: 32, -0, +3 tracks from HOME use only during data 
formatting. 


2e RECAL: 7/72, -0, +3 tracks from HOME use to initialize home posi- 
tion after power on or following an access or any other error. 


SEEK - coarse track positioning of data head to any desired track 
location. | 7 


TRACK FOLLOWING ~- heads are detented on a specific track location and 
the device is ready for another command. 


OFFSET - controlled microstepping of fine position system during 
TRACK FOLLOWING (two modes). 


1. COMMAND OFFSET - direction and amount of offset is specified to 
the servo. » 


2. AUTO OFFSET - command allows the servo to automatically move off 
track by the amount indicated by the embedded servo signal on the 
data surface (disk). _ 


STATUS = command can read servo status. 


DIAGNOSTIC ~ not implemented. 


-See Table 1 for the actual command description. With the present com- 


mand structure a SEEK COMMAND can be augmented with an OFFSET COMMAND. 
Upon completion of a seek, the offset command bit is tested to determine 
ia an offset will occur following a seek (either auto or command offset). 


oN 


A Sy 
fi NS 
5 


ee 


~ 
ee os _ 
: } 
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When a SERVO ERROR occurs the Z8 SERVO will attempt to do a short RECAL 


(ERROR RECAL). Two attempts are made by the system to do the ERROR RECAL 
function. If either of the two RECAL operations terminate successfully 
the protocol status will be SERVO READY, SIO READY and SERVO ERROR. 
Should the ERROR RECAL fail then the system will complete the error 
recovery by a HOME function. 


The two OFFSET commands will be described. First COMMAND OFFSET is a pre- 
determined amount of microstepping of the fine position servo. Included 
in the OFFSET BYTE (STATREG) bit B6=0 is a COMMAND OFFSET. Bit B7=1 is a 
forward offset step (toward the spindle); B7=0 is a reverse step. In the 
case bit B6=l1 the OFFSET command is AUTO OFFSET. 


AUTO OFFSET command normally occurs during a Write operation. When the 
HDA was initially formated at the factory special encoded servo data was 
written on each track “near” the index zone. The reason for this follows: 


Normal coarse and fine position information for the position servos is 
derived from an optical signal relative to the actual data head-track 
location. Over a period of time the relative position (optical signal) 
will not be aligned to the absolute head-track position by some unknown 
amount (less than 100 uln). This small change is important for reliabil- 
ity during the write operation. Write/Read reliability can be degraded 
due to this misalignment. The special disk encoded servo signal is avail- 
able to the fine position servo and will correct the difference between 
the relative position signal of the optics and the absolute head to track 


position under the data head only at index time. The correction signal 


can be held indefinitely or updated (if desired at each index time) or 
until a new OFFSET command or move command (SEEK or RECAL) occurs. 


COMMUNICATION FUNCTIONS 


The servo functions described in the previous section only occur when the 
servo Z8 microprocessor is in the communication state. Communication 
states occur immediately after a system reset, upon completing head set- 
ting after a recal, seek, offset, read servo status or set servo diag= 
mostic. A special communication state exists after a servo error has 
occurred. If + SIO READY is not active no communication can exist between 
the external controller and the servo Z8 processor. 


Servo commands are serial bits grouped as five separate bytes total. Re- 
fer to Table 1 parts I through V as the total communication string. First 
byte is the command byte (i.e. seek, read status, recal, etc.). Second 
byte is the low order difference for a seek (i.e. Byte 2 = SOA is a ten 
track seek). Third byte is the offset byte (AUTO or COMMAND OFFSET and 
the magnitude/direction for command offset). Fourth byte is the status 
and diagnostic byte (use for reading internal servo status or setting 
diagnostic commands). Byte five is the check sum byte used to check ver- 
ify that the first four bytes were correctly transmitted (communication 
error checking). | 


Ill. 


Part of the communication function requires a specific protocol between es 
the servo 28 processor and the external controller. ae 


Servo control and communication are described in CHART I. This chart 
illustrates the basic sequencing and control operations. Chart I does 
not illustrate the servo error handling or command/protocol handling 


functions. Error handling is described in Section IV and illustrated by 
CHART II. _ 


Z8 SERVO PROTOCOL 


The protocol between the Z3 SERVO microcomputer and the CONTROLLER is 
based on five L/O lines. Two of the I/O lines are serial input (to Z8 
servo from controller) serial output (from Z8 servo to controller). Data 
stream between the Z8 servo and controller is 8 bit ACSII with no parity 
bit (the fifth byte of the command string contains check sum byte use for 
error checking). There are three additional output lines between the 28 
servo used as control lines to the controller. Combining the two serial 
I/O lines and the three unidirectional port lines generates the bases of 


the protocol between the Z8 servo and controller. The important opera- 


tions between the Z8 servo and controller are: 


ihe Send commands to Z8 servo. 


2« Read Z8 servo status. 


ed 


3. Check validity of all four command bytes. 
4. 1/0 timing signals between the Z8 servo and controller. 


5. 2Z8& servo reset. 


Sequencing the Z8 servo controller is an important process following a 
Power Up (Power On Reset) or if the controller should issue a Z8 Servo 
Reset at any time. After a Z8 Servo Reset is inhibited the Z8 I/O ports 
and internal register are initialized. This takes approximately 75 msec 
after the Z8 Servo Reset is inhibited. The protocol baud rate is auto- 
matically set to 19.2KB and then the system is parked at HOME position 
and SIO READY is set active. ***IMPORTANT***. If the desired baud rate 
needs to be increased to 57.6KB; **after a Z8 Servo Reset is the ONLY 
time this can be done***. Once set to 57.6KB the communication rate re- 
mains at 5/.6KB until a Z8 Servo Reset occurs. Setting 5/.6KB is achieved > 
as follows: 


1. Z8 Servo "Power On or Controller" Reset 


ye Wait for S1O Ready 


Z 
- > 


on 

| ic 

3. Send a READ STATUS COMMAND as follows: Nh 
BYTE 1 = $ 00 
BYTE 2 = 3 00 
BYTE: 3° = $00 
5S 87 


BYTE 4 = 


After the completion of transmitting the bytes, the Z8 Servo Controller - 


chanzges to 57.6KB and will be waiting for the next transmitted command 
at 57.6KB. 


Before the controller transmits the command byte the controller must pole 
the SIO READY line from the Z8 servo to determine if it is active (+5 
volts). If the line is active then a command can be transmitted to the 
Z8 servo. The program in the Z8.servo will determine what to do with the 
command bytes (depending upon the current status of the Z8 servo). After 
the command (five bytes long) has been transmitted to the Z8 servo, the 
program in the Z8 servo will determine if the command bytes (first four 
bytes) are in error by evaluating the check sum byte (fifth byte trans- 
mitted). See table Chart III and IV for the error handling. After the 
controller has transmitted the last serial string it must wait 250 usec 
then test for SERVO ERROR active (+5 volts). If SERVO ERROR is active the 
command was rejected (check sum error or invalid command). If the SERVO 
ERROR is set active 6004sec after the command is sent (and not 250 sec), 
this was a command reject. The SERVO ERROR must be cleared by READ 
STATUS COMMAND or RECAL COMMAND before transmitting another command. 

See CHART 1 for time diagram of the command sequence and 1/0 protocol. 


As long as SIO READY is active the controller can communicate with the Z8 
Servo Controller. If SERVO READY is not active the only command that will 
cause the Widget Servo to set SERVO READY active is a RECAL COMMAND (NOR- 
MAL or FORMAT). Read Status will only clear SERVO ERROR. And all other 
commands will be rejected. 


Next, if SERVO READY is active and SERVO ERROR is also active, SERVO 
ERROR can be cleared by: 


l. Any READ STATUS COMMAND. 
2. Any RECAL COMMAND. 


3. Any other commands will be rejected and maintain SERVO ERROR. 

: if 
If a SEEK COMMAND is transmitted with both SERVO READY and SERVO ERROR 
active the command will be rejected. 


It is important to check the status of all three status lines from the 
Z8 Servo. It is best to avoid sending a SEEK COMMAND with SERVO READY 
and SERVO ERROR active. 


Chart V parts A-I illustrate some of the serial communication commands 
and error conditions that can occur between the controller and Z8 SERVO. 


~" “ERROR HANDLING 


SERVO ERROR will be generated during the following conditions: 


il. During Recal mode (velocity control only) access time-out.If a Recal 


function exceeds 150 msec then an access timeout occurs. 


During Seek mode (velocity control only) access time-out. If a Seek 
function exceeds 150 msec then an access timemout occurs. | 


During Settling mode (following a Recal, Seek, or Offset) if there is 
excessive On Track pulses (3 crossings) indicating excessive head 
motion a Settling error check will occur. 


During a command transmission if a communication error occurs (check 
Sum error). 


During a command tansmission if a invalid command is sent. 


—_ 


z 


C 


re 
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APPENDIX A: 


Lie 


The purpose of the FINE POSITION SERVO is to maintain detent or lock on 
a given data track. Any misregistrations of the head/arm due to windage, 
mechanical observed by the optics position signal are corrected by the 
close loop position servo. Misregistrations at the data head relative to 
the actual data track on the disk must be corrected by the AUTO OFFSET 
command. Figure I illustrates a block diagram of the Widget FINE POSI- 


_ TION SERVO. The amount of misregistration at the data track sensed after 


a AUTO OFFSET command are summed into the servo and the servo is automat- 
ically repositioned over the data track. 


The COARSE POSITION SERVO (SEEK) has the function of moving the data 
head arbitarily from a current track to any other arbitrary track loca- 


-tion within the total number of track locations between the inner to 


outer crash stops. When a command is transmitted to the Z8 Servo con- 
troller, the Z8 decodes and interprets the command into a servo function. 
If a SEEK command is sent to the Z8 Servo Controller a direction and 
number of tracks to move is also sent. The system starts its move to the 
new track location. When the arm has moved to its new location the Z8 
Servo Controller provides control and delay necessary to allow the data 
head and the FINE POSITION SERVO to come to rest immediately following a 
SEEK. This insures that motion in FINE POSITION SERVO and data head will 
be under control when the READ/WRITE channel begins operation. Reliabil- 
ity of the data channel is assured with high margins. Figure L illustrates 


a block diagram of the Widget COARSE POSITION SERVO. 


The differences between the FINE POSITION SERVO and the COARSE POSITION 
SERVO is handled by the Z8 Servo Controller. The two servos share for 
the most part the same set of electronics. The 23 Servo Controller and 
analog multiplexers switch between the signal paths. In general there 
are some circuits that dare not shared because of their uniqueness for a 
particular servo. 


maqe i 
TABLE 1 | 
e 
I. BYTE 1: COMMAND BYTE (OIFCNTH) 
| BY BS BS B4 } FUNCT IONS 
-—— i {| @ @ @ access anly 
iB? (' 1 @ 8 1 ¢ Access with offset | 
command i864 1 @ t a 8 i; mormal recal (to trk 2) 
hits 1 BS i @ | 1 1 | format recal (ta trk Se) 
i Bs ' @ 86 a | | offset-trk following 
=a 1 of { 8 4 | hame-send to ID stop 
=== (| @ @ tf @ 4: diagnastic command 
i183 ~-X—~ not used ; 6@ 6 8 6 | Read status command 
access 'B2 ~-access direction sw rrr rrr eee 
bits (Si -hi di¢f2 (512) 
iB@ -hi diffi ¢256) 
access direction = 1 (FORWARD: toward the spindle) 
| = @ (REVERSE: away from the spindle) _ 
hi diff#2 (S12) = 1 (512 tracks to god as 
= 8 (not set) 
hi diff! ¢€256) = 1 (256 tracks to qo) 
| = 4 (not set) 
Il. BYTE 2: DIFF BYTE <¢OIFCNTLD 
command BYTE 2 contains the LOW ORDER DIFFERENCE COUNT for a seek 
'B7 -bit7= 128 tracks 
iBS -bi té= 44 tracks 
(B85 -bi tS3= 32 tracks 
(B4 -bi td= 16 tracks 
'B3 -bit3a= sg tracks 
(O62 ~-bit2= 46. tracks 
‘Bi =-bitrti= 2 tracks 
(BY -bitd= I track 
fs 


28 SERYO COMMAND 8SYTES 


meg | 23 SERVO COMMAND BYTES 
TABLE 1 


0). BYTE 3: OFFSET BYTE <STATREG: 


command BYTE 3 contains the INSTRUCTION for an OFFSET COMMAND (seek 
or during track following) 


-offset directian 
~auto offset function 
“read offset value Cafter autea or manual ? 
~oftfeet Bbitd =16 
—~mafrfseftf bits =8 
“offset bit2 =4 
“offset biti =2 
“offset bith =! 


NI 


a-ha d & Ol oO. 


vmnonmnwonowow wD 


i. if offset command from BYTE 1 is followed br bits set Cauta orfse: 
Offset direction (bit?) read offset (bitss and bits 4-4 ars ignores 
But should be set to Bb if mot used. 


2. OFFSET DIRECTION =1 ¢FORWARD OFFSET: toward the spindle) 
=9 (REVERSE OFFSET: away from the spind|e) 


{ 3. AUTO OFFSET =1 (normally used preceeding a write operation) 
- =4 (manual offset:MUST send direction and magni tt 
Of offset? 
4. RESD OFFSET ={ Cread offset value from DACsi.e. after aure 
7 oftset) 


=4@ (no actiand 


* READ OFFSET COMMAND desired after AUTO OFFSET MUST be sent as 
seperate commands 


I. BYTE 4: STATUS BYTE ‘CCNTREG? 


(BY =-communication rate 

(BS -power on reset 

i835 -not used 

(B4 =-nat used 

i'B3S w~etatus or diagnostic Bits 
i62 - 

iBil - a 

Teo. = 2 


Bf=8; Communicatian Rate | 
={;3} Communication Rate | 


seh 


S.2c KBRUD © 

7.6 KBGU0. | ar ae 

Res: Power On Reset Bit fs no sch we 
=1l: Pewer On Rasear Birk | 


ae 


ace ee 
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WIDGET SERVO FUNCTIONAL OBJECTIVE 


BASIC SERVO FUNCTIONS 


Widget servo control functions are handled by a Z8 microprocessor. The 
Z8 handles all 1/0 operations, timing operations and communication with a 
host controller. Control functions to the Z8 Servo Controller are made 
through the serial 1/0. ; 


The following commands for the Widget servo are: 
A. HOME —- not detented, heads off data zones located at the inner stop. 
Be RECAL — detented at one of two positions. 


1. FORMAT RECAL: 32, -0, +3 tracks from HOME. Used only during 
data formatting. 


2e RECAL: 72, -0, +3 tracks from HOME. Used to initialize home 
position after on or following an access error or any other 
error. 


C. SEEK — coarse track positioning of data head to any desired track 
location. 


D. TRACK FOLLOWING — heads are detented on a specific track location and 
the device is, ready for another command. 


E. OFFSET —- controlled microstepping of fine position system during 
TRACK FOLLOWING (two modes). 


1. COMMAND OFFSET - direction*and amount of offset is specified to 
the servo. 


2. AUTO OFFSET — command allows the servo to automatically move off 
track by the amount indicated by the embedded servo signal on the 
data surface (disk). 


F. STATUS — command can read servo status. 

G. DIAGNOSTIC —- not implemented. 

See Table 1 for the actual command description. With the present. com 
mand structure a SEEK COMMAND can be augmented with an OFFSET COMMAND. 


Upon completion of a seek, the offset command bit is tested to determine 
if an offset will occur following a seek (either auto or command offset). 


Live 


When a SERVO ERROR occurs the Z8 SERVO will attempt to do a short RECAL 
(ERROR RECAL).. Two attempts are made by the system to do the ERROR RECAL. 
function. If either of the two RECAL operations terminate successfully 
the protocol status will be SERVO READY, SIO READY and SERVO ERROR. 
Should the ERROR RECAL fail then the system will complete the error 
recovery by a HOME function. | 


The two OFFSET commands will be described. First COMMAND OFFSET is a pre= 
determined amount of microstepping of the fine position servo. Included 
in the OFFSET BYTE (STATREG), bit B6=0 is a COMMAND OFFSET. Bit B/7=l1 is a 
forward offset step (toward the spindle); B7=0 is a reverse step. 

If bit B6=1, the OFFSET command is AUTO OFFSET. 


AUTO OFFSET command normally occurs during a write operation. When the 
HDA was initially formated at the factory, special encoded servo data was 
written on each track “near” the index zone. The reason for this follows: 


Normal coarse and fine position information for the position servos is 
derived from an optical signal relative to the actual data head-track 
location. Over a period of time, the relative position (optical signal) 
will be misaligned to the absolute head=-track position by some unknown 
amount (less than 100 uIn). This small change is important for reliabil- 
ity during the write operation. Write/Read reliability can be degraded 
due to this misalignment. The special disk encoded servo signal is avail- 
able to the fine position servo. It will correct the difference between 
the relative position signal of the optics and the absolute head to track 
position under the data head only at index time. The correction signal 
can be held indefinitely or updated (if desired at each index time) 

until a new OFFSET command or move command (SEEK or RECAL) occurs. 


COMMUNICATION FUNCTIONS 


The servo functions described in the previous section only occur when the 
servo Z8 microprocessor is in the communication state. Communication 
States occur immediately after a system reset, upon completing head set- 
ting after a recal, seek, offset, read servo status or set servo diag- 
nostic command. A special communication state exists after a servo error 
has occurred. If + SIO READY is not active, no communication can exist 
between the external controller and the servo Z8 processor. 


Servo commands are serial bits grouped as five separate bytes total. Re- 
fer to Table 1 parts I through V for the total communication string. 

The first byte is the command byte (i.e. seek, read status, recal, etc.). 
The second byte is the low order difference for a seek (i.e. Byte 2 = SOA 
is a ten track seek). The third byte is the offset byte (AUTO or COMMAND 
OFFSET and the magnitude/direction for command offset). The fourth byte 
is the status and diagnostic byte (use for reading internal servo status 
or setting diagnostic commands). Byte five is the check sum byte used to 
check verify that the first four bytes were correctly transmitted 
(communication error checking). 


= 


_—_ 


Piet sm SARE ale eek OR AGRE cat Ratha Nate NE a ewe eet tet ale ee eee ine Seen une en, eee el nee al i a TS A ee ee tem a er i a ee eee Scalia, ec ae! Macca “aca 6 cea Nweg ahti >» SR rtatini “2 “led ati 


» 


Til. 


Part of the communication function requires a specific protocol between 
the servo Z8 processor and the external controller. 


Servo control and communication are described in CHART I. This chart 
illustrates the basic sequencing and control operations. Chart I. does 
not illustrate the servo error handling or command/protocol handling 
functions. Error handling is described in Section IV and illustrated by 
CHART II. | 


Z8 SERVO PROTOCOL 


The protocol between the Z8 SERVO microcomputer and the CONTROLLER is 
based on five I/O lines. Two of the I/O lines are serial input (to 28 
servo from controller) serial output (from Z8 servo to controller). Data 
stream between the Z8 servo and controller is 8 bit ASCII with no parity 
bit (the fifth byte of the command string contains check sum byte use for 
error checking). There are three additional output lines between the Z8 
servo used as control lines to the controller. Combining the two serial 
I/O lines and the three unidirectional port lines generates the bases of 
the protocol between the Z8 servo and controller. The important opera- 
tions between the Z8 servo and controller are: 


1. Send commands to Z8 servo. 

2. Read Z8 servo status. 

3. Check validity of all four command bytes. 

4, 1/0 timing signals between the Z8 servo and controller. 
5. 2Z8 servo reset. 


Sequencing the Z8 servo controller is an important process following a 
Power Up (Power On Reset) or if the controller should issue a Z8 Servo 
Reset at any time. After a Z8 Servo Reset is inhibited, the Z8 I/O ports 
and internal register are initialized. This takes approximately 75 msec 
after the Z8 Servo Reset is inhibited. The protocol baud rate is auto- 
matically set to 19.2KB and then the system is parked at HOME position 
and SIO READY is set active. ***IMPORTANT***, If the desired baud rate 
needs to be increased to 57.6KB; **after a Z8 Servo Reset is the ONLY 
time this can be done***, Once set to 5/.6KB the communication rate re= 
mains at 5/7.6KB until a Z8 Servo Reset occurs. Setting 5/.6KB is achieved 
as follows: 


Ll. Z8 Servo "Power On or Controller" Reset 
2. Wait for SIO Ready 


3. Send a READ STATUS COMMAND as follows: 


BYTE 1 = $ 00 
BYTE 2 = $ 00 
BYTE 3 = $ 00 
BYTE 4 = 


$ 87 


IV. 


After the completion of transmitting the bytes, the Z8 Servo Controller 
changes to 57.6KB and will be waiting for the next transmitted command 
at 57. 6KB. “e 


Before the controller transmits the command byte the controller must pole 
the SIO READY line from the Z8 servo to determine if it is active (+5 

volts). If the line is active then a command can be transmitted to the 

Z8 servo. The program in the Z8 servo will determine what to do with the 
command bytes (depending upon the current status of the Z8 servo). After 

the command (five bytes long) has been transmitted to the Z8 servo, the 
program in the 28 servo will determine tf the command bytes (first four 
bytes) are in error by evaluating the check sum byte (fifth byte trans- 
mitted). See Charts III and IV for the error handling procedures. After the 
controller has transmitted the last serial string it must wait 250 usec 

then test for SERVO ERROR active (+5 volts). If SERVO ERROR is active the 
command was rejected (check sum error or invalid command). If SERVO 

ERROR is set active 600 U sec after the command is sent (and not 

250 U sec), this was a command reject. The SERVO ERROR must be cleared 

by a READ STATUS COMMAND or RECAL COMMAND before transmitting another command. 
See CHART 1 for the timing diagram of the command sequence and I/0 protocol. 


As long as SIO READY is active the controller can communicate with the Z8 
Servo Controller. If SERVO READY is not active the only command that will 
cause the Widget Servo to set SERVO READY active is a RECAL COMMAND (NOR= 
MAL or FORMAT). Read Status will only clear SERVO ERROR, and all other 
commands will be rejected. 


Next, if SERVO READY is active and SERVO ERROR is also active, SERVO 
ERROR can be cleared by: 


1. Any READ STATUS COMMAND. 
2. Any RECAL COMMAND. — 
3. Any other commands will be rejected and maintain SERVO ERROR. 


If a SEEK COMMAND is transmitted with both SERVO READY and SERVO ERROR 
active, the command will be rejected. 


It is important to check the status of all three status lines from the 
Z8 Servo. It is best to avoid sending a SEEK COMMAND with SERVO READY 
and SERVO ERROR active. 


Chart V, parts Ag-I, illustrate some of the serial communication commands 
and error conditions that can occur between the controller and Z8 SERVO. 
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ERROR HANDLING ~ 
SERVO ERROR will be generated during the following conditions: 


1. During Recal mode (velocity control only) access time~out.If a Recal 
function exceeds 150 msec then an access timeout occurs. 


During Seek mode (velocity control only) access time-out. If a Seek 
function exceeds 150 msec then an access time-out. occurs. 


During Settling mode (following a Recal, Seek, or Offset) if there is 
excessive On Track pulses (3 crossings), indicating excessive head 
mortony a Settling error check will occur. : 


During a command transmission if a communication error occurs (check 
sum error). 


During a command tansmission if a invalid command is sent. 


APPENDIX A: 


Il. 


The purpose of the FINE POSITION SERVO is to maintain detent or lock on 
a given data track. Any misregistrations of the head/arm due to windage, 
mechanically observed by the optics position signal are corrected by the 
close loop position servo. Misregistrations at the data head relative to 
the actual data track on the disk must be corrected by the AUTO OFFSET 
command. Figure I is a block diagram of the Widget FINE POSITION 

SERVO. The amount of misregistration at the data track sensed after 

an AUTO OFFSET command is summed into the servo and the servo is automat- 
ically repositioned over the data track. 


The COARSE POSITION SERVO (SEEK) has the function of moving the data 

head arbitrarily from a current track to any other arbitrary track loca- 
tion within the total number of track locations between the inner to 
outer crash stops. When a command is transmitted to the Z8 Servo con= 
troller, the Z8 decodes and interprets the command into a servo function. 
If a SEEK command is sent to the Z8 Servo Controller a direction and 
number of tracks to move is also sent. The system starts its move to the 
new track location. When the arm has moved to its new location the Z8 
Servo Controller provides control and delay necessary to allow the data 
head and the FINE POSITION SERVO to come to rest immediately following a 
SEEK. This insures that motion in FINE POSITION SERVO and data head will 
be under control when the READ/WRITE channel begins operation. Reliabil- 
ity of the data channel is assured with high margins. Figure I is a block 
diagram of the Widget COARSE POSITION SERVO. 


The differences between the FINE POSITION SERVO and the COARSE POSITION 
SERVO is handled by the Z8 Servo Controller. The two servos share for 

the most part the same set of electronics. The Z8 Servo Controller and 
analog multiplexers switch between the signal paths. In general there 

are some circuits that are not shared because of their uniqueness for a 
particular servo. 
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APPENDIX B: 


An important part of the Widget Servo System is the optics signal. The optics 
signal provides the necessary signals for the fine position servo to position the 
data head accurately over the data track and to provide the system velocity 
signal during seek mode. The alignment of the optics signal is described in 

the following section on "WIDGET OPTICS ALIGNMENT PROCEDURE." 


Dan Retzinger 
Nov. 9, 1982 


WIDGET OPTICS ALIGNMENT PROCEEDURE 


INTRODUCTION 


The purpose of this note is to describe the procedure for properly adjusting 
five pots on the widget mother board used to contro] the amplitude of the optics 
Signal. The five pots are R7, R8, R17, RI9 and R35. The optics signal 
Originates at the end of the servo arm and is used in positioning the arm. 


EQUIPMENT REQUIRED 


An oscilloscope capable of operating in the X-Y mode of operation. A Tektronix 
model 465 works fine. 


PROCEEDURE ° 


Optics LED Drive Adjustment 


1. Connect channel 1 of the oscilloscope to TP 5 on the Widget Mother Board. 
2. Scope Vert. setting: 1 Volt/Div. Horizontal: Any sweep rate. 
3. Adjust 835 so the voltage at TP5 is 3.6 volts +/- .2 volts. 

(clockwise, or more resistance=]ower voltage) 


Figure 1: TP5 Amplitude 
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. Position A and Position B Adjustment 


4. Put scope in X-Y mode, ground channels X and Y, move dot to 
center of screen. 

« Connect chan X to TP9, chan Y to TP8. (Both TP's are located 
near pin 1 of the Z8 microprocessor) 

- Scope vertical: Chan X and Y, 2 volts/Div. 

. At this point. arm is to be moved. ** to be determined how ** 

- With arm in movement, a circular pattern should appear on the 
scope. Adjust. R7, R8, R17, R19 so the top, bottom, right 
and left sides of the circle come at but no closer than a 
minimum of 2.5 scope divisions from the center of the screen. 

9. Each pot adjusts the circle as follows: 


R7 Left side clockwise or lower res=smaller circle 
R8 Right side ‘ 
R17 Bottom | " 
R19 Top - 


10. Figure 2 shows a properly adjusted optics signal. 


Figure 2: Position A and 8B 
MIA. 
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PROCEEDURE SUMMARY 
1. Adjust R35 so the voltage at TP5 (R37) is 3.6 Volts +/- .2 volts. 


2. Put scope in X-Y mode, chan 1 & 2 set to 2 volts/div. Adjust 27, 
R8, R17, R19, so that the sides of the circle (during minimum 
i, fluctuation) are each within 2.5 Divisions (+/- .1 div) of the 
( 3 | | center. This corresponds to 5 Volts from the center to the 
- top, Dottom, or either side. | 
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ADDITIONAL INFORMATION NEEDED FOR WALT WEBBER 


To provide information to convert. the resistor trimming process into a laser 
trimming process, Walt Webber needs the following information: 


1. The actual final resistor value of R34 and R35 on a properly adjusted mother 
board. (LED current drive adj.) 


2. The final resistor value of the resistor pairs for adjusting the sides of 
the circle: pairs RP1 and R7, RPL and R8, RPL and R17, RP1 and R19. 


3. Data from 20 to 50 boards is necessary for a good cross section. 
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APPENDIX C: 


Some of the analog control signals can be useful in understanding or evaluating 
the function or performance of the Widget Servo. Photographs are provided to 
illustrate some of the key Widget functions. Refer to the following document 
"WIDGET SERVO WAVEFORMS." 
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WIDGET SERVO 


VARIOUS KEY WAVEFORMS 
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CONTENTS 


Optics Adjustment 

Current Sense and Position A 

Current Sense and Position A (Forward and Rev Seeks) 
Velocity and Position A 

Velocity and Position A (Forward and Rev Seeks) 

DAC Output and Position A 

DAC Output and Position A (Forward and Rev Seeks) 
Curve Shift Function and Position A ( 1 track seek) 
Curve Shift Function and Position A (60 track seek) 
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WAVEFORM: Optics Adjustment 


Scope Adjustments: 


Channel 


Chan l 
Chan 2 
Trig In 


Horiz 


Servo: 


Probe Tip Test Point 
Position A TP9 
Position B TPs 

Not used 

X-Y Mode 


Alternate Seeks, 512 tracks 


Press Z; 


$24. Os 0. 16 
86, 0, 0, 0 
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Notes 


2V/div 
2V/div 


WAVEFORM: Current Sense and Position A 


Scope Adjustments: 
Channel Probe Tip 


Chan l Current Sense 
Chan 2 Position A 
Trig In Access Mode 


Horiz: S5ms/Div Calibrated 


, servo: 


Test Point 


tP19 
TP9 
TP2/ 


Alternate Seeks, 96 tracks (Hex 
re : 


Press Z; 80, 60, 0, 0 
84, 60, 0, 0 
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Notes 


_ V/div 
_: 5V/div 


Positive trig, Ext/10 
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WAVEFORM: 


Current Sense and Position A 
(Forward and Reverse Seeks) 


Scope Adjustments: 


Servo: 


Channel Erobe Tip Test Point Notes 

Chan 1 Current Sense TP19 5V/div 

Chan 2 Position A TP9 SV/div 

Trig In Access ‘ode TP27 Positive trig, Ext/10 


Horiz: 2ms/Div Uncalibrated 


Alternate Seeks, 96 tracks (Hex $60) 


Press Z; 80, 60, 0, 0 
| 84, 60, 0, 0 
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WAVEFORM: Velocity and Position. A 


| 
(_ Scope Adjustments: 


Channel 


Chan 1 
Chan 2 
Trig In 


Horiz: 


Servo: 


Probe Tip 


Velocity 
Position A 
Access Mode 


5ms/Div Calibrated 


Test Point 


TP7 
TPY 
Te Ls 


Alternate Seeks, 96 tracks (Hex 560) 


Press Z; 


80, 60, 0, 0 
84, 60, 0, 0 
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Notes 


—2N/div 


5V/div 
Positive trig, Ext/10 
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WAVEFORM: Velocity and Position A 
(Forward and Rev Seeks) 


Scope Adjustments: 


Channel Probe Tip | Test Point ects 

Cis l Velocity TP7 sii 

Chan 2 Position A TP9 SV/div | 

Trig In Access Mode TP 27 Positive trig, Ext/1l0 


“Horiz: 2ms/Div Uncalibrated 


Servo: 
Alternate Seeks, 96 tracks (Hex $60) 


Press 2; 80, 60, 0, 0 
84, 60, 0, 0 
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WAVEFORM: DAC Output and Position A 


= 


(. Scope Adjustments: 


servo: 


Channel Probe Tip 


Chan 1 DAC Output 
Chan 2 Position A 
Trig In Access Mode 


Horiz: 5ms/Div Calibrated 


‘Test Point 


TP13 
TP9 
£P2/ 


Alternate Seeks, 96 tracks (Hex $60) 


Press Z; 80, 60, 0, 0 
84, 60, 0, 0 


— _ anne en, Ee ee 
- ce ee, - = . 


Notes 


2V/div 
5V/div 
Positive trig, Ext/1l0- 
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qc. 


WAVEFORM: DAC Output and Position A 
(Forward and Rev Seeks) 
Scope Adjustments: 
Channel Probe Tip 
Chan 1 DAC Output 


Chan 2 Position A 
Trig In Access Mode 


Horiz: 2ms/Div Uncalibrated 


Servo: 


Test Point 


Alternate Seeks, 96 tracks (Hex $60) 


Press Z; 80, 60, 0, 0 
84, 60, 0, 0 


Notes 


2V/div 
5V/div 
Positive trig, Ext/10 
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WAVEFORM: Curve Shift Function and Position A 
(Forward and Rev Seeks: 1 track) 


( 


Scope Adjustments: 


Channel Probe Tip Test Point Notes 


Chan l Curve Shift Func. TP12 2V/div 
Chan 2 Position A TP9 5V/div - 
Trig In Access Mode TP27 Positive trig, Ext/10 


Horiz: 2ms/Div Uncalibrated 


Servo: 
Alternate Seeks, 1 track 


Press 2Z; 80, O1, 0, O 
84, 01, 0, 0 
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WAVEFOR!H: Curve Shift Function and Position A 
(60 track seek) 


Scope Adjustments: 


Channel Probe Tip Test Point Notes 
Chan l| Curve Shift Func. TP12 2V/div 
Chan 2 Position A TP9 5V/div 
Trig- In Access Mode TP 27 Positive trig, Ext/10 


Horiz: 5ms/Div Calibrated 


Servo: 
Alternate Seeks, 96 tracks (Hex $60) 


Press Z; 80, 60, 0, 0 
84, 60, 0, 0 
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28 SERVO COMMAND BYTES 
' TABLE 1 


—_ 


I. BYTE 1: COMMAND BYTE (¢DIFCNTH) 
| BY B6 BS B84: FUNCTIONS 

=o > 1 @ @ @ |: access only 

iB i 1 @ 6 ft } access with offset 
command iBé : @ 1 6 @ ! normal recal (to trk 72) 
bits :BS ; @ {| 1. f | format recal ¢to trk 32) 

184 ' @ 86 @ tL | offset—-trk following 

——= i £ 1 6 6 {| home-send to ID stop 

=a ' @ @ 1 8 ! diagnostic command 

{83 —-X—- not used | @ 6 6 6 { read status command 
access iB2 -access direction  -ew we 9 a nn nr rr = - 
bits (B81 ~-hi diff2 ¢512) 


(BO -hi diffi ¢256) 


access direction = 1 (CFORWARD: toward the spindle) 
= @ (REVERSE: away from the spindle) 
hi diff2 ¢512) = 1 ¢Si2 tracks to go) 
= @ (not set?) 
hi diffi ¢2546) = 1 (256 tracks to qo) 
= @ (not set) 
IT. BYTE 2: DIFF BYTE (CDIFCNTLD 


command BYTE 2 contains the LOW ORDER DIFFERENCE COUNT for a seek 


{B87 -bit7= 128 tracks 
(B86 —bité= 64 tracks 
(‘BS -bitS= 32 tracks 
(B84 -bitd= 156 tracks 
(BS -pit3= 8 tracks 
182 -bit2= 4 tracks 
(B81 -biti= 2 tracks 
-bitg= ft track 


i B@ 


Z8 SERVO COMMAND BYTES : page2 
( TABLE 1 
i 


III. BYTE 3: OFFSET BYTE ‘STATREG) 


command BYTE 3 contains the INSTRUCTION for an OFFSET COMMAND ( seek 
or during track following) *. 


[BY ~offset direction 

'BS6 ~auto offset function - ; 
(B85 eed —e poeta eee ears er —ranrtrato- MOT USED 
'B4 -offset bitd =15_ 

iB3 ~-offset bit3 =8 

'B2 -offset bit2 =4 

i'B1 ~offset biti =2 

(B88 ~-offset bita =1 


i. if offset command from BYTE 1 is followed by bits set Cauta offset) 
offset direction (bit7) read offset (bitS> and bits 4-@ are ignorec 
but should be set to @ if not used. 


2. OFFSET DIRECTION =1 (FORWARD OFFSET: toward the spindle) 
=9 (REVERSE OFFSET:away from the spindle) 


—_ 3. AUTO OFFSET =1 (normally used preceeding a write operation) 
. = (manual offset:MUST send direction and magni tuc 
of offset? 
es ae Sa Saes sie 
a ee a 


IV. BYTE 4: STATUS BYTE CCNTREG? 


iB? -communication rate 

iBS ~power on reset 

(BS -not used 

i'B4 =-not used 

(B83 -status or diagnostic bits 


iB2 = i 
iBl = 
iBa - 4 
( ) B7=6; Communication Rate is 1%.2 KBAUD 
o =1; Communication Rate is 37.6 KBAUD 
Bs 


40; Power On Reset bit is no active 
1; Power Qn Reset Bit is active 


23 SERVO COMMAND BYTES pages 
TABLE 1 


- 


(y. BYTE 5: CHECKSUM BYTE (CKSUM) 


<fB?7 Bé BS 84 BS B2 Bi Ba) 


results of the transmitted CHECKSUM BYTE are derived as: 


(BYTE 1 + BYTE 2 + BYTE 3 + BYTE 4) = CHECKSUM BYTE 


C+) is defined as the addition of each BYTE 


- €BYTE) is defined as the compliment of the BYTES‘ 1-4) 


VI. The SERVO STATUS lines ¢SIO RDY,SERVO RDY,SERVO ERROR) must have the 
following conditions in order to send the listed 28 COMMANDS: 


SERVO STATUS 


$ =) Ss 
I R R 
0 V V 
R R W~& 
D. D R 
Y Y R 
ZS SERVO CMD HEX 
accessconly? 8X ii 1 Qi 
accesstCoffset) 9X i 1 @} 
recaltdata)D 48 ii x xi 
recal¢format) 7G if x xi 
park Ca 11 x xi 
offsetCdetent>) 14 il 1 8} 
status g8 if xX xi 
diagnostic 2g SSS sS== ; not implimented 


X= either @,1 


wf SERVO SEQUENCES 
CHART I 


SYSTE k4: 
RESET 


SYSTEM stat TiAdL/2ATION 


CLEAR Poe? AND THEN O)/,2 
CueAR REGS 1/27 40 of 
ShP STACE Rosnsvte 


SZQ COtgusuulCAsIols SET UP 


SET S$t0 70 48.64£28 


SELAL COLvsawAs(CnToed 


PARK 


RECALL STATE 


PRES AAD NAIT LOOP 
CORD T/MEZS 


SET Peers 


Tote Ae RS oR i ENN cee a 


/ 


can 
i 


STATE 


{t 


© 


i¢ 


TN a mE EP LO NR Uheiant cane Aneel + eminent. eaten Mean 


Ze SERVO SEQUEVCER 
CHALr x 


S7TR-RT RECAL. t4OTIO 


STHRT TIhaGeS 


— Sér Zeq waAse (71) 


TL=0 CMoveo zEequieeD T2ACE LENGTH) 


RECALL EIN fel APPROACH 


SEr CRhRQ MASE 


SEP PeRT og 
PERL ( S7OP VELociTY 
COMmDITIUMS GM TRACE 


SETTLING Conureed 


Sh. PORTS FOR SETTLING 
STRREr HEAD SETTLING TIMER 


Loma TRACK CeesS ING Course CTL) 


STRar TL 
TEST FOR OFFSET 8/r 


SEF AITEGRATOR GA/ 


CE fam) | 


Z8 Seve SEQuUBWCEe 
CHher x 


" 
ser 
Cae 


r 
STRAT SZO COMM ULC ATION) 
{Chr 
DECODE : 
RECAG NOT 4 Ph / MauTED 
CLD 


ACCESS ‘Srare (SEEKS 


SEP SE2R Dierccron 


S&T PORTS 


L6AB AWD START 7, Tl TimEBS 


SET SEZ CURVE 


—sS 
N 


SEEK FIMAL APPROACH 


SET PORTS 


UPDATE PasvTiow SI@NAL FOR SETTINGS 


TERY 


LRQA FOR TERM ConwDITION 
CONDI TIO: : 


—— 
as 
a8 


oS ee ee RD ee ae ANN * OS OT aN 1 ae NaN tee ate s : 3 5 3 a 
a ts A albert Neate ee Ole a OE TNT OE art ae aS Ry A Le SE LOE Ste ke en ae 


SEe0V6 ELeCOR 
CHser IT 


SEP SE2vO FREOR 


witti TRY The RETRIES 


a 


mr re ne 8 ete tee 0 teen Sit ree ae LAE HST 7. OE EN, ae ES eed nee an eer ee en, wd Oe epee oe ee Ree ae - ~ 


COMM UM/ CATION EPREGLS 
CHAPT TT 


STATE 1,7 


SLO 2EADY 


ERROR N 


= DESELEC?T” SISO READY 


VE 


COW UALWOD 
CHART IZ 


wi 
1 <Bisices> 
Aig SRT EF] 

y 


Pa 
Sar 2D STAT 


SET SZaw 
SRO R 


COse 44 wD 


LGA CwdD 
Ada LOCaT 


+ ee ons AEE NT 


ELEORS 


t 
4 


RETECr 


| “CHART V A- Ruwee ve 


—>| _— Apprecuuakt SO m 


q f2ve BESET 


szomoy WW t___U| - 
Stew 2DY V/s n/a 
seeyy seegn § MI/lf | Y, 


Slo ,' ConTeoezee Yb, UY 


B- AFTER Fowea uP — Cute Site Eeegse 


seav69 FleoR | a 


SEO COATED (2 ty B2 Keak Kes i 


C- ALTER RWEe OP —/NUALID Cur. 
od 
Slo by | see. 


SEeve dy 


SERVO LPL. 


SJ SERVe 


Sf pr ee, ee ee — inoceemcont Foreman eee pm 


So Coven Br { Ors Bah eales hk 


a | 
‘Craer lL D> REAO STATY SS COkrwAWD 


a. ap ES wy joe 
\ 


SIQ eDy \ 


SELYO FAY 


— 


seve feese ce 
SZO SERVO | : (e:Vs2\ sshesics) | 
Slo. Cow7ee X20) 3 2y83y ayy Cs \ | 


E=-724Ck FOLLOWING Séeyo Eeeo/e - INYRLID COMM AyD 


SrQ. FeLVO 


seas ei 


F=eTRACE FOLLOWING SERVE EXegR — BEAD STATUS 
—D l— \MSEC_ 


STO eoy : ! id 


SEevye 2v 


326 ‘3dERY6 


A fw 7 ee. | Sr \ sehen ae cs { 


¢. 4 
°" CHART G~repce FOLLOW UG YALUD Coumaud (Hove) 


SZ@ BdYy x—> | ) 
A ive poy | a ee 


SEReVvo FfRPOL2 ( f- 
ishvneamiecaeqsapssbiaiondenesamenssonel “ 
SIO * SPRVUS 


SEO + CO 7eN | KBIY B2XB3XBe Ves Y | . 


fA-7eAck ZetigwinG Chove Cd) Leet By Stevo Cea 
ns 


sSe@vo0 fby | . WI, Mf 
ESV LEPC —\. | | | 


Sd ata ' SEZ 6 


SOO | CONTEC (oi XB2Y BH Byes 


Do —7eack. FOLtLcow swe CKvO CounAwDd ) SELY@ Ff0/2 


SIO eDy | ) V2. Wi Mf W/L VA; 


eve boy — WITT (11117. 
SE eve Feeare _| 
SZO .SFL2Y¢ 


Sessa SS SSSI psn SSS SSG ssn esesatsnnenaasssenensetsniantittns 
Slo CONTRL 


(> 


im, DUA MODE cc Dog T/0K SFRVO /0 fle 2 om 


(Ke NID (OUVRSE POS17IOKN SELVOS ) we 
PuLSE A,B C2) | | eee 
TACH Cl OPTICS 
PHASE A,B\COMUEET 
(2) 
| / x. 
Ss? 


SALT PLE PES 


FIGURE ZL 


